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ABSTRACT 
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The  Simulation  of  A  Parallel  Processor  Based  Small  Tactical  System  is  a  part  of 
The  Parallel  Command  and  Decision  System  (PARCDS)  Laboratory,  which  was 
established  in  early  1980’s  to  suppon  research  for  the  Navy’s  AEGIS  combat  system. 

Current  U.S.  Navy’s  AEGIS  system  using  the  standard  AN/UYK-7  computers, 
which  has  four  processors  in  the  computer  system.  When  one  of  them  fails,  the  system 
automatically  reloads  the  remaining  three  processors  with  software  that  has  a  reduced 
capability.  But  in  probably  less  than  one  decade,  they  will  not  be  capable  of  handling  the 
increasing  demand  for  some  more  complex  software  systems. 

Military  command  and  decision  systems  of  the  next  decade  must  be  characterized 
by  economy,  speed,  stability,  reliability,  and  ease  of  repair.  The  transputer  features  all  of 
these  benefits  and  provides  a  scalable  network  of  transputers  which  is  relatively  easy  to 
design.  The  need  for  parallel  processing  grows  more  evident  daily,  since  the  best  high- 
performance  uniprocessor  architectures  are  reaching  their  limits. 

The  prime  objective  of  this  thesis  is  to  model  a  small  tactical  system  by  using  a 
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I.  INTRODUCTION 


A.  BACKGROUND 

1.  Historical  Background 

Since  World  War  II,  the  development  of  radar  has  produced  spectacular 
changes  in  the  conduct  of  naval  warfare.  Jet  aircraft  replaced  their  propeller  driven 
predecessors.  The  increasing  speed  of  attackers  such  as  aircraft  or  missiles  was  seen  as 
a  reason  for  a  requirement  of  some  type  of  system  or  technique  to  gather  operational  data, 
process  the  data  into  meaningful  information,  and  present  the  information  as  fast  as 
possible  in  order  to  make  the  intercept  decisions. 

In  the  late  1950’s  and  early  1960's,  with  the  inception  of  the  Navy  Tactical 
Data  System  (NTDS),  the  U.S.  Navy  began  using  computers  in  tactical  shipboard  systems. 
The  Nasal  Tactical  Data  System  evolved  from  this  need  to  normalize  and  conven 
increasing  amount  of  information  from  multiple  sources  to  common  representations  that 
could  be  processed,  stored,  and  dis.seminated  to  shipboard  tactical  users  so  that  w'eapons 
employment  decisions  could  be  made  more  effective  with  less  reaction  time.  [Ref.  1] 

In  the  late  1970's  the  developers  had  the  primary  mission  of  investigating 
alternative  architectures  for  the  Aegis  combat  system.  Aegis,  named  after  the  shield  of 
Zeus,  was  originally  designed  for  the  U.S.  Ticonderoga  class  (CG-47)  guided  missile 
cruiser,  whose  central  unit  is  the  three  dimensional  Phase  Array  Radar  AN/SPY- 1.  the 
four  processors  computer  system  ANA-WK-7  and  the  weapons  control  system. 


In  early  1980’s  the  Parallel  Command  and  Decision  System  (PARCDS) 
Laboratory'  was  established  to  suppon  research  for  the  Navy’s  Aegis  combat  system.  The 
early  research  involved  tightly  connected  single-processor  systems  modelling  parallel 
processing.  The  following  decade  brought  many  advances  in  computing  power,  especially 
in  the  field  of  parallel  processing.  [Ref.2]. 

2.  The  Aegis  Combat  System 

The  Aegis  Combat  System  is  the  most  powerful  and  complex  combat  system 
available  to  the  surface  fleet  of  the  U.S.Navy.  The  Aegis  Combat  System,  designed  for 
guided  missile  cruiser,  was  engineered  as  an  integrated  system  of  computer  programs, 
sensors,  and  weapons  to  provide  a  multi-warfare  capability.  [Ref.3]. 

Aegis  consists  of  three  major  system  components.  These  are  the  powerful 
phase  array  multi-function  radar,  AN/SPY- 1,  the  command  and  decision  system  (C&D), 
and  the  weapons  control  system  (WCS).  The  SPY-l’s  function  is  to  detect  targets,  C&D 
perfomis  command,  control  and  communication  functions.  The  WCS  function  is  to 
evaluate  the  engagement,  provide  and  execute  fire  control  solutions  as  well. 

Since  the  technology  grows  rapidly,  the  U.S.Navy  keeps  trying  to  improve  the 
flexibility,  reliability  of  the  Aegis  Combat  System  by  investigating  the  possibility  of 
replacing  the  current  components  with  the  new  fashion  ones.  The  most  important  variable 
in  the  development  of  Aegis  Combat  System  is  the  reaction  time.  For  example,  there  was 
the  investigation  of  replacing  current  communication  network  for  the  Aegis  combat 
system  aboard  Naval  ships  with  dual  optical  fiber  rings  and  the  investigation  of  replacing 
the  old  expensive  AN/UYK-7  computers  with  parallel  computer  networks. 
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The  next  few  decades  will  see  the  design,  development  and  deployment  of  the 
next  generation  surface  combatant.  It  will  most  likely  be  built  upon  the  current  Aegis 
computer  system  architecture,  expanding  to  a  well  integrated,  highly  reliable  and  easily 
operable  real-time  combat  system. 

3.  Transputer  Review 

The  term  "transputer"  is  an  acronym  for  "transistor  computer"  where  it  reflects 
the  ability  of  this  device  to  be  used  as  a  system’s  building  block,  much  like  the  transistor 
was  in  the  past.  The  nice  feature  of  the  transputer  is  that  it  adds  a  new  level  of 
abstraction,  which  provides  a  very'  simple  way  to  design  a  concurrent  system.  As  a  formal 
definition  we  could  state  that  the  transputer  is  a  single-chip  microcomputer  that  has  its 
own  local  memory  and  four  communication  links.  The  links  may  be  thought  of  as  small 
special  purpo.se  processors  which  steal  no  cycles  from  the  main  CPU,  in  such  a  way  that 
we  could  have  all  four  links  and  the  CPU  working  at  the  same  time,  without  degrading 
the  performance  of  the  program's  execution.  fRef.4]. 

The  transputer  is  a  parallel  microprocessor,  generally  categorized  as  a  Multiple 
Instruction  Multiple  Data  (MIMD)  computer.  This  means  that  transputers  are  used  to 
execute  different  operations  on  separate  data  at  the  same  time.  A  transputer  operates  as 
a  stand-alone  machine  or  as  a  processing  element  interconnected  by  its  links  to  from  a 
computing  array  or  network  of  transputers.  [Ref.5]. 

The  IXMOS  IMS  T800  transputer  includes  a  fast  processor,  a  floating-point 
processor,  memory,  and  communication  facilities  in  one  chip.  The  IMS  T800  is  designed 
for  communication  in  a  network  of  transputers.  Each  transputer  has  four  link  engines. 
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each  of  which  suppons  a  bidirectional  communications  link  that  operates  as  a  direct 
memory  access  (DMA)  channel.  Transmission  rates  of  20  Mbps  per  link  may  be  achieved 
concurrently  as  the  T800  processor  continues  at  high  speed.  Our  estimates  are  that  the 
T800  computes  at  about  ten  times  faster  than  the  ANAJYK-7.  According  to  the 
performance  measurement  of  J.  Dongarra  [Ref.9],  the  T800  is  2.3  times  faster  than  the 
INTEL  80386/80387  combination  and  four  times  faster  than  the  MOTOROLA  68020. 

B.  ENVIRONMENT 

1.  Hardware  Environment 

The  designed  network  of  transputers  which  model  the  Small  Tactical  System 


using  the  IBM-compatible  (Zenith  Z-248)  microcomputer  that  hosts  the  IMS  T800  25 
Mhz  transputer  on  the  TMB  08  motherboard  (interface  between  host  transputer  and  PC) 
with  four  external  transputers,  as  shown  in  Figure  1. 


Figure  1:  PC  Host  with  Network  of  the  IMS  T800  Transputers 
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2.  Software  Environment 


a.  ADA  Programming  Language 

The  Ada  language  is  currently  undergoing  revision,  Ada  9x  as  a  new 
standard  Department  of  Defence  (DoD)  programming  language.  Ada  will  be  the  standard 
language  for  programming  computers  that  are  components  in  weapons  systems.  The 
language  incorporates  the  latest  concepts  in  algorithmic  language  design,  including 
modem  control  structures,  user  defined  data  type,  generic  units,  exception  handling,  and 
the  ability  to  coordinate  concurrently  executing  "tasks". 

It  is  asserted  that  Ada  can  be  used  as  a  specification  tool.  This  results 
from  the  ability  of  Ada  to  allow  top-down  program  development,  in  which  functionality 
can  be  omitted  at  a  high  level,  only  to  be  incorporated  at  a  later  time.  In  addition,  Ada 
incorporates  control  structures  for  multi-tasking,  in  which  concurrently  executing  tasks 
are  coordinated  in  a  special  way.  Information  may  be  passed  among  the  tasks  in  a  manner 
which  is  independent  of  the  underlying  computer  architecture.  (Ref.7]. 

b.  Alsys-Ada  Compilation  System 

In  October  1989,  Alsys  produced  the  first  compiler  capable  of  supporting 
multi-processor  programming  in  Ada.  The  PARCDS  laboratory  purchased  this  compiler 
for  the  transputer  systems.  Our  experience  in  using  the  Alsys-Ada  compiler’s  ability  to 
generate  Ada  code  for  a  single  processor  found  that  the  compilation  process  is  a  complex 
task,  even  in  the  uniprocessor  case.  In  spite  of  this  complexity  in  this  thesis,  the  Alsys- 
Ada  is  selected  to  be  the  compilation  tool  for  Ada  programs  in  a  multi-transputer  network. 
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c.  OCCAM  2  Toolset 


The  Occam  2  toolset  is  a  set  of  software  tools  for  developing  transputer 
programs  on  host  systems.  Used  with  the  occam  libraries,  it  provides  a  complete 
environment  for  developing  programs  on  transputers  and  transputer  networks.  The  toolset 
allows  Occam  programs  to  be  written  using  any  convenient  text  editor.  Application 
programs  are  then  compiled  and  linked  using  Occam  programs  resident  on  the  host  or 
running  on  transputer  board.  Self-booting  code  for  single  transputers  and  multi-transputer 
networks  is  produced  and  loaded  from  the  host  system  down  the  transputer  links. 

d.  MAKE  Program  Maintenance  Utility 

MAKE  is  a  utility  program  designed  to  assist  in  the  automatic  updating 
and  regeneration  of  computer  programs.  MAKE  provides  a  specialized  script  language  and 
an  interpreter  designed  to  facilitate  control  of  the  programming  environment.  MAKE 
program  automates  the  process  by  determining  which  parts  of  the  program  have  been 
changed  since  the  last  compilation  and  rebuilds  them  accordingly. 

MAKE  operates  by  processing  a  programmer  prepared  script  file  named 
"makefile".  MAKE  executes  a  list  of  information  provided  in  the  makefile.  Makefile 
contains  entries  that  describe  how  to  bring  a  target  object  code  up  to  date  with  respect  to 
those  on  which  it  depends,  called  "dependencies"  along  with  a  list  of  macro  definitions 
for  commands  needed  to  rebuild  the  modules  or  programs.  This  information  tells  MAKE 
which  system  commands  it  should  issue  to  process  individual  files.  Since  dependency  is 
a  target,  it  may  have  dependencies  of  its  own.  Targets  and  dependencies  comprise  a  tree 
structure  that  makes  traces  when  deciding  whether  or  not  to  rebuild  a  target. 
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MAKE  recursively  checks  each  target  against  its  dependencies,  beginning 
with  the  first  target  entry  in  makefile  if  no  target  argument  is  supplied  on  the  command 
line.  If,  after  processing  all  of  its  dependencies,  a  target  file  is  found  either  to  be  missing 
or  to  be  older  than  any  of  its  dependencies,  MAKE  rebuilds  it.  To  build  a  given  target, 
MAKE  executes  the  list  of  commands  called  a  rule.  This  rule  may  be  listed  explicitly  in 
the  target’s  makefile  entry,  or  it  may  be  supplied  implicitly  by  MAKE. 

C.  THESIS  OBJECTIVE 

The  basic  thrust  of  this  thesis  is  that  the  same  software  running  under  the  old 
expensive  AN/UYK-7  computer  could  run  equally  well  in  the  commercially  available 
VLSI  microprocessors.  And  as  expected,  in  probably  less  than  one  decade,  the  old 
fashioned  Navy’s  standard  computers  will  not  be  capable  of  handling  the  increasing 
demand  for  some  more  complex  software  systems. 

This  thesis  is  a  part  of  the  Parallel  Command  and  Decision  System  Laboratory', 
whose  researchers  investigate  the  possibility  of  replacing  the  old  standard  Navy’s 
computers  for  the  Aegis  real-time  combat  system  aboard  Naval  ships  with  the  network 
of  transputers  in  order  to  reduce  the  reaction  time  of  the  Command  and  Decision  Systems. 

The  objective  of  this  thesis  is  to  try  to  keep  up  with  the  upcoming  new  technologies 
especially,  the  TRANSPUTER.  The  investigation  has  been  made  by  modelling  the  Small 
Tactical  System  with  the  network  of  transputers,  based  on  the  standard  DoD  programming 
language,  ADA.  as  the  programming  language.  The  Alsys-Ada  compilation  system  is  used 
in  the  designed  network  of  transputers. 
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D.  THESIS  ORGANIZATION 


This  thesis  is  presented  in  five  chapters  and  eight  appendixes.  Chapter  I  was  the 
historical  background,  the  development  of  the  Navy’s  AEGIS  combat  systems  and  the 
introduction  to  the  new  fashion  of  the  commercial  VLSI  microprocessor,  TRANSPUTER. 

Chapter  II  provides  the  general  idea  of  the  designed  transputer  network 
implementation  of  the  Small  Tactical  System,  and  the  hardware  and  software  environment 
used  in  the  designed  network. 

Chapter  III  describes  the  design  of  each  subsystem  in  the  modelling  of  the  Small 
Tactical  System.  This  chapter  focuses  on  the  underlying  design  concepts  used  in  reaching 
the  objective  of  each  subsystem. 

Chapter  IV  focuses  on  the  software  development  in  Ada  by  using  the  Alsys-Ada 
compilation  system  and  the  Occam  2  toolset.  Executing  the  program  on  the  network  of 
transputers  to  perform  the  functions  of  the  Small  Tactical  System,  and  to  demonstrate  the 
communication  of  data  among  those  transputers  through  their  links. 

Chapter  V  states  the  conclusions  and  recommendation  for  future  research. 
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11.  SMALL  TACTICAL  SYSTEM  MODELLING 


A.  SIMULATION  OF  SMALL  TACTICAL  SYSTEM 

1.  General  Idea 

After  a  target  has  been  detected,  the  decision  is  made  either  to  attack  or  not. 
If  an  attack  decision  is  made,  then  the  target  is  tracked.  A  future  position  is  estimated, 
and  a  weapon  is  launched  to  intercept  the  attacker  at  the  predicted  interception  point.  To 
clarify  the  approach,  a  five  transputer  network  is  designed  to  solve  the  problem. 

2.  The  Designed  Network 

The  designed  network  of  modelling  the  Small  Tactical  System  using  the  IMS 
T800  25  Mhz  transputer  as  the  host  transputer  and  4  IMS  TSOO  20  Mhz  external 
transputer  as  the  subsystems  as  shown  in  Figure  2. 


PC 

TO 

T1 

T2 

T4 

T3 

igure  2;  The  designed  Small  Tactical  System 
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To  is  the  host  transputer  which  performs  the  Human  Interaction. 

T,  performs  as  the  Target  Tracker  Subsystem. 

Tj  performs  as  the  Target  Prediction  Subsystem. 

T3  performs  as  the  Ballistic  Interception  Subsystem. 

T4  is  a  hot  spare  to  make  the  system  Fault  Tolerant. 

3.  The  Designed  network  Configuration 

The  designed  multi-transputer  network  implementation  of  the  Small  Tactical 
System  is  required  to  have  the  transputer  boards  as: 

-  the  IMS  B417  TRAM  (TRAnsputer  Module) 

-  the  TMB08  TRAM  Motherboard 

-  the  IMS  B003  Evaluation  Board 


the  network  has  been  connected  as  shown  in  the  Figure  3. 
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The  connection  of  the  designed  network  is  made  by  using  two  soft  wires.  One 
is  connected  the  down  subsystem  from  the  TMB08  to  upload  a  program  at  the  8003 
board  and  the  other  one  is  connected  link  2  of  the  1800  25  Mhz  in  the  TMB  08  board 
to  link  0  of  the  fmst  T800  20  Mhz  in  the  8003  evaluation  board  as  shown  in  Figure  4. 


TMB08  37  pins 
D-Type  Connector 


BOOS  Connector 


-igure  4;  External  Links 

When  all  connections  have  been  made,  there  is  a  check  program  that  ctm  check 


the  connections.  Output  of  the  check  program  will  look  like  below 


check  1.21 
#  Part  rate 

Mb 

8t  [  LinkO 

Linkl 

Link2 

Link3  ] 

0 

T800d  -25 

0.18 

0 

[ 

HOST 

1:1 

2:0 

...  ] 

1 

T2  -17 

0.90 

1 

[ 

•  •• 

0:1 

... 

C004  ] 

2 

T800c  -20 

0.90 

0 

1 

0:2 

... 

3:3 

4:2  ] 

3 

T800c  -20 

0.90 

3 

[ 

•  •• 

5:3 

2:2  ] 

4 

T800c  -20 

0.90 

2 

[ 

•  •  • 

•  *. 

2:3 

5:2  ] 

5 

T800c  -20 

0.88 

3 

[ 

... 

4:3 

3:2  ] 
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B.  TRANSPUTER  BOARDS 


1.  The  IMS  B417  TRAM  (TRAnsputer  Module) 

The  IMS  B417  is  a  TRAnsputer  Module  (TRAM)  incorporating  a  IMS  T800 
25  Mhz  transputer,  64K  bytes  of  static  RAM  and  4K  bytes  of  dynamic  RAM.  The  4M 
bytes  of  DRAM  is  sufficient  to  run  the  Ada  compiler  from  Alsys.  The  IMS  B417  is  board 
level  transputer  with  a  simple,  standardized  interface.  The  circuit  diagram  of  the  IMS 
B417  TRAM  is  shown  in  Figure  5. 


a.  The  IMS  T800  25  Mhz  Transputer 

The  IMS  TSOO  25  Mhz  transputer  is  a  32-bit  CMOS  microcomputer  with 
a  64  bit  floating  point  unit  and  graphic  support.  It  has  4K  Bytes  on-chip  RAM  for  high 
speed  processing,  a  configurable  memory  interface  and  four  communication  links.  It  is 
able  to  perform  floating  point  operations  concurrently  with  the  processor.  The  32  bit  wide 
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memory  interface  uses  multiplexed  data  and  address  lines  and  provides  a  data  rate  up  to 
4()M  bytes/s.  A  configurable  memorv'  controller  provides  all  timing,  and  DRAM  refresh 
signals  for  a  wide  variety  of  mixed  memory  systems. 

b.  Memory  Configuration 

The  IMS  B417  is  able  to  access  4M  bytes  of  memory'.  This  is  comprised 
of  4K  bytes  of  internal  transputer  memory,  60K  bytes  of  external  SRAM  and  4032K  bytes 
of  external  DRAM.  There  :ire,  in  fact,  64K  bytes  of  SRAM  components  and  4M  bytes  of 
DR.A.M  components  on  the  module,  but  the  address  space  of  each  type  of  memory  are 
superimposed.  Therefore,  the  total  memory  available  is  limited  to  4M  bytes  which  is 
sufficiei'it  to  run  Ada  compiler  product  of  Alsys.  The  start  addresses  of  the  different  types 
('['  external  memory  on  the  IMS  B417  is  shown  in  table  below  ; 


Hardware  bytes  address 

SRAM  From  : 

#  80001000 

To  : 

#  8000FFFF 

DRAM  From  : 

#  80010000 

To  : 

#  803FFFFF 

2.  The  TransTech  TMB08  TRAM  Motherboard 

The  TMBOS  is  a  TR.4M  motherboard  that  enables  users  to  build  multi- 
trumputer  system  that  can  be  plugged  into  an  IBM  PC-XT  or  PC-,AT.  It  has  slots  for  up 
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to  ten  TRAMs.  By  using  an  IMS  C004  programmable  link  switch,  incorporated  on  the 
TMB08  allows  a  large  variety  of  networks  to  be  created  under  software  control.  The  IMS 
C004  link  switch  is  controlled  by  the  T2 12  16-bit  transputer.  An  interface  to  the  IBM  bus 
is  provided  so  that  a  program  running  on  the  IBM  PC  can  control  the  TRAMs  on  the 
TMB08  board.  Different  events  on  the  TMB08  can  generate  an  interrupt  on  the  IBM  PC 
and  the  PC  can  carry  on  with  other  tasks  while  programs  are  running  on  the  TMB08.  The 
diagram  of  the  TMB08  is  shown  Figure  6. 


IBM  PC  bus 


Figure  6:  The  Transtech  TMB08  TRAM  Motherboard 


a.  The  IMS  T2I2  Transputer 

The  IMS  T2 1 2  integrates  a  1 6-bit  microprocessor,  four  standard  transputer 
communication  links,  2K  bytes  on-chip  RAM,  a  memory  interface  and  peripheral 
interfacing  on  a  single  chip.  The  processor  shares  its  time  between  any  number  of 
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concurrent  processes.  A  process  waiting  for  communication  or  a  timer  does  not  consume 
any  processor  time.  The  T212  use  a  DMA  block  transfer  mechanism  to  transfer  message 
between  memory  and  another  transputer  product  via  links.  The  link  interface  and  the 
processor  all  operate  concurrently,  allowing  processing  to  continue  while  data  is  being 
transferred  on  all  of  the  links.  The  2K  bytes  of  static  RAM  provide  a  maximum  data  rate 
of  40M  bytes/s  with  access  for  both  the  processor  and  link.  The  T212  can  directly  access 
a  linear  address  spaces  up  to  64K  Bytes,  and  has  a  16-bit  wide  data  bus  and  a  16-bit  wide 
address  bus,  non-multiplexed,  providing  a  data  rate  of  up  to  20M  bytes/s,  and  supporting 
word  or  byte  organization. 

b.  The  IMS  C004  Programmable  Link  Switch 

The  IMS  C()04  device  is  a  transparent  programmable  link  switch  designed 
to  provide  a  full  crossbar  switch  between  32  link  inputs  and  32  link  outputs.  Any  of  32 
links  may  be  connected  to  any  other  by  sending  the  appropriate  control  data  to  the  IMS 
C0()4  along  its  configuration  link.  The  configuration  link  of  the  IMS  C004  is  connected 
to  an  IMS  T212  transputer.  Configuration  data  for  the  IMS  C004  is  fed  into  link  1  of  the 
IMS  T212  (ConfigUp),  which  then  passed  it  on  to  the  IMS  C004  on  link  3.  The  same 
data  is  also  passed  out  of  the  IMS  T212  through  link  2  to  the  edge  of  the  TMB08  board. 

c.  The  IMS  CO  1 2  Link  Adapter 

The  IMS  CO  12  link  adapter  is  a  universal  high  speed  system  interconnect, 
providing  full  duplex  transputer  link  communication  by  converting  bi-directional  serial 
link  data  into  parallel  data  stream.  The  IMS  C012  provides  an  interface  between  an 


INMOS  serial  link  and  a  microprocessor  system  bus.  Two  interrupt  outputs  are  provided, 
one  to  indicate  that  input  data  is  available  and  one  for  output  buffer  empty.  There  are  two 
link  adapters  in  the  TMB08  board,  one  connects  between  PC  and  the  IMS  B417  TRAM 
and  the  other  one  connects  between  PC  and  the  IMS  T212  transputer.  In  the  TMB08 
motherboard,  the  status  of  the  registers  of  IMS  C012  are  continuously  polled  by  software 
running  on  PC. 

3.  The  IMS  B003  Evaluation  Board 

The  IMS  B(X)3  evaluation  board  (T800  20  Mhz  version)  is  a  double  extended 


Eurocard  containing  four  T800  20  Mhz  transputers.  The  four  transputers  are  synchronized 
by  using  the  same  clock  in  the  logic  shared,  as  shown  in  the  Figure  7. 
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a.  The  IMS  T800  20  Mhz  transputer 


The  IMS  T800  20  Mhz  transputer  is  a  32-bit  microprocessor  with  a  64 
bit  floating  point  unit,  four  standard  transputer  communications  links,  4K  bytes  of  on-chip 
RAM  and  a  memory'  interface  on  a  single  chip.  The  T800  20  Mhz  provides  high 
performance  arithmetic  units  and  microcode  support  for  floating  point  operations.  The 
processor  shares  its  time  between  any  number  of  concurrent  processes.  The  link  interfaces 
and  the  processor  all  process  concurrently,  allowing  processing  to  continue  while  data  is 
being  transferred  through  all  of  the  links.  The  32  bit  wide  memory  interface  uses 
multiplexed  data  and  address  lines  and  provides  a  data  rate  of  26. 6M  bytes/s.  The  IMS 
T800  20  Mhz  is  pin  compatible  with  the  IMS  T414  20  Mhz,  if  the  additional  inputs  of 
the  IMS  T800  are  held  to  ground.  The  IMS  T800  20  Mhz  can  thus  be  plugged  directly 
into  a  circuit  designed  for  a  20  Mhz  version  of  the  IMS  T414.  Software  should  be  re¬ 
compiled,  although  no  changes  to  the  source  code  are  necessary'. 

b.  Links 

The  transputers  on  the  board  are  connected  in  a  square,  the  square  has 
rotational  symmetry,  with  link  2  of  each  transputer  connected  to  link  3  of  the  next 
transputer.  Link  0  and  link  1  of  each  transputer  are  taken  to  the  edge  connector.  The 
speed  of  communication  between  links  for  internals  on  board  running  at  20M  bit.s/s,  while 
Link  Os  are  connected  off  the  board  and  running  at  lOM  bits/s.  Alternatively,  all  the  links 
may  be  set  to  run  at  lOM  bit.s/s  or  20M  bit,s/s.  But  if  running  external  links  at  20M  bits/s, 
the  link  connections  have  to  be  short.  The  link  connection  to  the  B003  board  depend  on 
the  designed  program. 
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C.  THE  ALSYS  ADA  COMPILATION  SYSTEM 


The  Alsys  Ada  Compilation  System  consists  of  the  Compiler  and  Binder,  operating 
in  the  Alsys  Multi-Library  Environment.  The  Compiler  generates  executable  code  for  T4 
or  T8  transputer  targets.  Multi-Library  Environment  provides  a  powerful  way  of  managing 
Ada  development  efforts.  It  allows  compilation  units  to  be  flexibly  shared  among 
libraries,  and  eliminates  the  need  to  copy  library  units  to  share  them,  along  with  the 
associated  version  control  problems. 

1.  The  Compiler 

The  Compiler  requires  two  names  as  input:  the  source  file,  which  contains  the 
Ada  source  code  and  a  program  library  in  w'hich  to  place  the  compiled  object  units. 
Compilation  units  in  the  source  file  must  be  specified  in  a  valid  order  such  that  if  a  unit 
depends  upon  other  units,  then  those  other  units  must  come  before  that  unit.  If  the  order 
of  the  units  is  invalid,  or  if  a  unit  named  in  a  with  clause  does  not  exist,  the  Compiler 
will  issue  an  error  message  and  the  compilation  will  fail.  The  output  from  the  Compiler 
normally  consists  of  an  update  version  of  the  designated  program  library,  containing  the 
compiled  object  code  for  the  units  included  in  the  source  file  and  a  compilation  listing 
detailing  the  results  of  the  compilation. 

The  compilation  listing  always  includes  diagnostic  message  for  any  errors 
detected  during  compilation.  There  are  options  to  include  in  the  listing  both  the  source 
code  of  all  compiled  units  and  the  object  code.  The  listing  may  be  sent  to  a  standard 
output  device  or  a  file  to  which  the  listing  is  to  be  written.  Alternatively,  the  compiler  can 
perform  an  error  analysis  without  generating  any  object  code.  If  this  is  the  case,  only  a 
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a  compilation  listing  will  be  produced  and  the  program  library  will  not  be  modified  in  any 
way.  The  error  analysis  can  be  restricted  to  syntactic  errors  only,  or  both  syntactic  and 
semantic  error  analysis  can  be  requested. 

2.  The  Binder 

The  Ada  Binder  combines  the  required  units  of  an  application  program  into 
an  object  module.  The  input  to  the  Binder  consists  of  an  Ada  program  library  containing 
the  main  unit  of  the  Ada  program  and  the  name  of  the  main  program  unit  within  this 
library.  The  Binder  uses  the  main  program  name  supplied  together  with  the  dependence 
information  in  the  program  library  to  find  the  compilation  units  needed  by  the  program. 
Other  related  units  can  be  contained  in  other  libraries  to  which  links  are  established  from 
the  current  library  (these  related  libraries  may  then  refer  to  future  libraries  and  so  on). 

The  Binder  produces  two  files  as  output:  an  object  module  containing  the  code 
and  data  for  all  the  Ada  compilation  units  included  in  the  program.  Default  name  is 
"prograrn.O"  and  a  listing  of  file  summarizing  the  results  of  the  binding  process.  The 
default  name  of  this  file  is  "program.BND".  The  listing  file  includes  any  error  message 
output  by  the  Binder.  The  listing  may  optionally  include  information  and  warning 
message,  information  about  the  composition  of  the  program,  the  elaboration  order  of  the 
program’s  compilation  units  and  the  names  of  any  subprograms  which  are  uncalled  in  the 
program  and  have  thus  been  deleted.  If  names  are  not  specified  for  the  Binder  output  file, 
default  file  names  based  on  the  main  program  name  will  be  used.  If  errors  are  detected 
during  binding,  no  object  module  will  be  produced. 
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3.  Linking,  Loading  and  Executing 

The  tasks  of  linking,  loading  and  execution  are  performed  using  programs 
provided  as  part  of  the  Occam  2  toolset,  a  set  of  tools  supplied  by  INMOS  to  aid  with 
the  development  of  transputer  based  applications. 

a.  The  Occam  2  Toolset 

There  are  a  number  of  different  implementations  of  the  toolset  running 
on  a  variety  of  host  computers.  However,  the  basic  facilities  provided  by  the  toolset  are 
the  same  regardless  the  implementation.  The  tools  which  are  of  particular  interest  are: 

ilink.  collects  together  all  the  code  for  a  program  resolving. 
ihoot.  A  tool  which  adds  a  bootstrap  code  to  link  programs  prior  to 
loading  the  program  on  a  single  transputer. 

iconf.  A  tool  which  configures  a  program  prior  to  execution  on 
multi-transputers  network. 

iserver.  The  host  server,  loads  bootable  program  onto  a  processor. 

This  implementation  of  the  toolset  uses  particular  command  line  syntax 
and  file  naming.  The  file  naming  conventions  are  particularly  evident  in  the  area  of  file 
name  extensions.  Most  extensions  are  composed  of  single  letter  code  followed  by  two 
additional  characters,  where  the  single  letter  identifies  the  nature  of  the  file: 

cxx  Linked  code  files,  the  output  of  ilink. 

.nixx  Mcxiule  map  produced  by  ilink. 

.hx.x  Bootable  code  file,  the  output  of  ihoot. 

.(Lxx  Bootstrap  code  description  produced  by  ihoot. 
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The  additional  characters  Cxr)  serve  to  identify  the  transputer  type  and 
error  mode  of  compilation.  For  the  Alsys  Ada,  the  error  mode  used  is  STOP  process  (s) 
mode,  so  the  second  additional  character  is  always  an  "s".  The  processor  type  can  be  any 
one  of  "4”,  "5",  or  "8"  corresponding  to  a  T414,  a  T425,  or  any  T8  transputer  target. 

b.  Program  Linking 

For  a  system  of  multiple  Ada  programs,  or  a  system  of  programs  running 
on  multiple  transputers,  it  is  likely  that  you  will  have  to  invoke  the  linker  directly  rather 
than  have  the  Binder  do  this.  Linking  is  accomplished  using  the  ilink  tool.  The  linker  is 
given  the  names  of  any  separately  compiled  object  or  library'  files  and  produces  a  single 
object  file  which  can  then  be  loaded  onto  a  transputer  system,  ilink  accepts  commands 
with  the  following  syntax 

ilink  {  inputfile  )  {  option  ) 

For  the  current  implementation  the  complete  list  of  input  files  which  must 
be  supplied  to  the  linker  in  addition  to  the  Binder  output  file  is  as  follows: 

■  harness. tSs.  The  occam  harness  used  to  invoke  the  Ada  program. 

■  adartsH.lib.  A  library  of  routines  which  form  the  part  of  the  Run 
Time  Executive  which  has  not  been  implemented  in  Ada. 

■  occamSs.lib.  The  occam  compiler  library  which  is  provided  as  the 
Occam  2  toolset  for  some  of  the  occam  routines  in  adarts8.1ib  to  reference. 

■  hostio.lib.  Another  library'  from  the  Occam  2  toolset;  it  provides 


access  to  the  facilities  of  the  iser\er. 


c.  Program  Loading  and  Execution 


Although  the  linker  produces  a  single  object  file,  there  is  still  a  step 
required  before  the  program  can  be  executed.  It  is  necessary  to  distributed  the  program 
among  the  network  of  transputer.  For  multi-transputer  programs,  executable  code  is 
produced  using  the  configuration  tool  iconf. 

D.  THE  ENVIRONMENT  OF  AN  ADA  PROGRAM 
1.  Interface  to  Host  System 

All  access  to  the  services  of  the  host  MS-DOS  operating  system  is  via  an 
interface  conforming  to  the  INMOS  file  server.  The  server  is  used  to  invoke  a  program 
to  be  run  on  the  transputer  and  continues  execution  on  the  host  (MS-DOS)  w'hile  the 
program  is  running. 

Communication  between  the  server  and  the  program  is  via  a  pair  of  channels; 
one  channel  is  used  for  requests  by  the  program  and  the  other  for  responses  from  the 
server.  For  single  processor  programs  these  channels  are  passed  as  parameters  to  the 
program.  For  multi-processor  programs,  the  channels  are  accessed  via  the  physical  links 
on  the  root  transputer.  Although  the  server  is  a  single  resource  which  can  only  be  used 
by  a  single  process  running  on  the  root  transputer,  it  is  possible  to  share  the  server 
resource  using  a  multiplexor  process.  The  multiplexor  takes  the  channels  request  from 
matn  processes  wishing  to  use  the  server  and  maps  them  onto  the  actual  server  channels, 
ensuring  that  the  communications  between  the  server  and  its  clients  do  not  overlap. 
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2.  Interface  to  Other  Languages 


a.  Ada  Program  Interface 

An  Ada  program  may  be  called  in  much  the  same  way  as  a  normal  Occam 
prcxredure.  All  Ada  programs  conform  to  the  following  occam  specification: 

PROC  Alsysadaentrypoint  (  []  INT  wsl,  in  out,  ws2) 

The  name  "Alsysadaentrypoint"  is  the  default  entry  point  name  of  an  Ada 
program.  The  default  occam  harness  contains  a  #IMPORT  directive  referring  to  the  file 
alsys.tax  which  consists  of  a  dummy  occam  procedure  conforming  to  the  above 
specification.  This  technique  allows  the  default  occam  harness  to  be  used  with  any  Ada 
program,  avoiding  the  need  to  change  the  #IMPORT  directive  and  thus  re-compile  the 
harness  for  each  program. 

It  is  possible  to  specify  an  alternative  entry  point  name  using  the  Binder 
option  ENTRY_P01NT.  When  this  option  is  used  together  with  the  Binder  option 
LEVEL=B1ND,  a  customized  occam  harness  can  include  a  #IMPORT  directive  referring 
to  the  output  file  of  the  Binder  (the  ".O"  file)  and  invoke  the  Ada  program  using  the  entry 
point  name  specified. 

The  |n  and  out  parameters  are  vector  of  pointers  to  channels  going  to  and 
coming  from  the  Ada  program.  If  there  is  a  single  workspace  (that  is,  there  is  no  stack 
memory),  the  wsl  parameter  is  used  as  the  main  workspace  and  the  ws2  parameter  is 
unused.  If  there  are  two  workspaces,  the  wsl  parameter  is  used  as  stack  memory  and  the 
v2  parameter  is  used  as  the  main  workspace.  Stack  memory  is  an  area  which  is  assumed 


to  map  onto  the  low-addressed  fast  internal  memory  of  the  transputer.  If  insufficient 


workspace  is  passed  by  the  Occam  harness,  the  Ada  program  will  be  terminated 
immediately  and  a  message  issued  along  the  error  channel.  Four  of  the  channel  parameters 
of  an  Ada  program  are  reserved  for  use  by  the  run-time  system: 

■  out[0]  is  used  as  an  error  channel. 

■  in[0]  is  reserved  although  currently  unused. 

■  out[  1 J  is  used  for  the  requests  from  the  Ada  program  to  the  server. 

■  in[l]  is  used  for  the  communication  of  responses  from  the  server. 
All  .A.da  input-output  operations  are  accomplished  by  issuing  requests  to 

the  server  and  therefore  make  use  of  the  channels  reserved  for  such  communication.  The 
following  routines  from  the  host  file  server  library,  hostio.lih,  are  potentially  called  from 
a  program  using  the  predefined  input-output  package  of  Ada: 

so.open,  so. close,  so.read,  so.write,  so.geis,  so.puts,  so.remove,  so.time 

Note  that  the  standard  input  and  standard  output  files  of  TEXT_IO  are 
mapped  onto  the  standard  input  and  standard  output  streams  of  the  server.  The  error 
output  from  the  Ada  program  is  treated  as  a  special  case  and  is  directed  to  the  error 
channel  rather  than  making  use  of  the  server  directly.  Severe  error  situations  are  reported 
along  this  channel,  including  program  deadlock  and  the  unhandled  exceptions. 

b.  Occam  Calling  Ada  -  the  Occam  Harness 

In  order  to  integrate  Ada  with  other  languages  a  well  defined  interface 
is  required.  Although  the  Ada  program  interface  is  adequate,  a  simpler  interface  is 
possible  if  the  program  could  be  treated  as  a  true  occam  process.  Ada  programs  may  then 
be  run  in  parallel  on  a  single  processor  or  distributed  across  a  multi-transputer  network, 
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just  as  Occam  processes.  To  achieve  this  simplicity  of  interface,  an  occam  process  called 
a  harness  is  used  as  a  wrapping  for  the  Ada  program.  A  default  Occam  harness  is 
provided  as  part  of  the  Compilation  System  in  both  source  and  compiled  forms.  The  main 
body  of  the  harness  consists  of  three  processes  operating  in  parallel: 

■  A  multiplexor  which  combines  the  error  output  and  the  output  of 
the  Ada  program.  This  process  is  provided  as  part  of  the  server  library,  hostio.lib. 

■  An  error  channel  collector  which  collects  any  output  from  L  e 
error  stream  and  routes  it  to  the  standard  output  stream  of  the  server  via  the  multiplexor. 

■  A  process  which  sets  up  the  input  and  output  channel  vectors  of 
the  Ada  program  and  then  invokes  it.  informing  the  other  processes  upon  compilation. 

When  all  three  processes  have  terminated,  the  .server  itself  is  terminated 
and  control  is  returned  to  the  host.  It  should  be  note  that  the  default  harness  is  suitable 
only  for  single  Ada  piograms  running  on  single  transputers. 

3.  Communication  Using  Transputer  Channel 

An  Ada  program  can  communicate  with  any  other  program  using  transputer 
channels  via  the  implementation  defined  package  CHANNELS.  This  program  could  be 
running  on  the  same  transputer,  or  on  one  of  its  neighboring  processors.  The  CHANNELS 
package  provides  access  to  the  channel  parameters  of  the  Ada  program  and  to  the 
physical  links  of  the  prcK'es.sor  on  which  the  program  is  running.  A  generic  package 
within  CHANNELS  provides  facilities  for  communication  between  programs  by  using 
READ  and  WRITE  operation  on  channels. 


a.  Using  Internal  Channels 

Channels  mapped  to  transputer  links  are  known  as  hard  channels. 
Processes  communicating  with  each  other  on  the  same  transputer  use  internal  channels, 
known  as  soft  channels,  implemented  in  the  transputer’s  memory.  These  internal  channels 
are  represented  in  Ada  by  objects  of  the  type  CHANNEL_TYPE  declared  in  package 
CHANNELS.  Any  number  of  such  channels  may  be  declared  in  an  Ada  program  and  used 
for  communicadon  between  tasks. 

b.  Accessing  Physical  Links 

Access  to  physical  links  and  the  event  pin  of  the  transputer  on  which  the 
Ada  program  is  running  via  the  channel  contents  declared  in  package  CHANNELS. 

c.  Communicating  Data  Across  Channels 

Channel  communication  can  be  achieved  using  the  READ  and  WRITE 
procedures  of  the  generic  package  CHANNEL_IO,  instantiated  with  an  appropriate  type. 
The  following  points  should  be  noted  w'hen  using  CHANNEL_IO  for  communication: 

■  Objec'  of  a  task  or  private  type  or  records  containing  components 
of  such  types  should  not  be  passed  into  or  from  an  Ada  program. 

■  Representation  and  length  clauses  should  be  used  to  control  the 
layout  and  size  of  record  objects  when  communicating  with  a  non-Ada  program. 

■  When  a  channel  is  used  for  communication  between  two  Ada 
programs,  common  packages  should  be  used  to  ensure  that  each  of  the  programs  has  a 
consistent  view  of  the  data  passed  between  them. 
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III.  SUBSYSTEM  DESIGN  AND  DEVELOPMENT 


A.  SINGLE  TRANSPUTER  SYSTEMS 

In  the  first  step  of  Small  Tactical  System  development,  it  is  necessary  to  ensure  that 
each  subsystem  is  done  correctly.  The  single  transputer  system  is  used  to  test  each 
subsystem  separately. 

For  single  transputer  systems,  the  major  issue  in  the  design  is  that  of  sharing 
resources.  The  resources  of  a  single  transputer  system  are  the  processor,  memory'  and  the 
server.  The  occam  programming  model  consists  of  a  number  of  processes  executing  in 
parallel  and  communicating  by  the  use  of  channels.  The  processes  which  constitute  a 
system  may  be  executing  on  the  same  transputer.  As  a  consequence  of  the  model,  it  is 
possible  for  several  programs  to  share  the  resources  cf  a  single  processor.  Since  an  Ada 
program  does  not  interfere  with  the  shared  components  of  the  system,  one  or  more  Ada 
programs  could  fonn  the  system.  However,  the  performance  (cost)  of  an  Ada  program 
should  always  be  taken  into  account  in  the  design  of  a  single  processor  system. 

A  single  transputer  system  is  invoked  as  a  single  program  (a  harness)  which  is 
passed  to  two  areas  of  free  memory:  a  work  space  and  an  area  of  stack  memory.  It  is  the 
responsibility  of  the  programmer  to  divide  these  workspaces  as  appropriate.  The 
workspace  allocation  is  provided  in  the  harness  "main.occ"  in  APPENDIX  F. 

To  implement  an  application  on  a  single  transputer  involves  four  logical  steps: 
Source  Compilation.  Object  linking.  Configuring.  Loading  and  Running. 
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1.  Source  Compilation 


All  application  source  must  be  compiled  for  the  target  transputer.  The  Alsys- 
Ada  compilation  systems  permit  separate  compilation  of  source  units.  Once  all  source 
units  have  been  compiled,  the  application  can  be  linked. 

a.  Source  of  Occam  Harness 

The  default  harness  is  inadequate  only  in  case  where  additional  channel 
parameters  need  to  be  passed  to  the  Ada  program.  Each  Ada  program  has  its  own  "mini- 
harness”  which  provides  a  clean  interface  to  the  program  in  terms  of  the  channels  used. 
The  main  harness  is  used  to  invoke  each  of  the  mini-harnesses  in  parallel.  Source  of  the 
Occam  harness  must  have  the  extension  ".occ". 

b.  Source  of  Ada  Program 

All  the  code  written  in  Ada  can  be  run  on  a  transputer  using  the  Alsys- 
Ada  Compilation  system.  It  can  support  any  standard  package  written  as  an  Ada  program. 
The  application  Ada  programs  must  have  the  filename  extension  ".ada". 

2,  Object  Linking 

For  a  single  Ada  program  running  on  a  tran.sputer,  invoking  the  Binder  alone 
should  be  sufficient  to  produce  an  object  file  named  "proj.o”.  Following  source 
compilation,  the  object  binaries  are  linked  together  with  the  relevant  run-time  library  and 
a  proprietary  occam  support  harness.  Linking  is  accomplished  using  the  ilink  tool.  The 
linker  is  given  the  name  of  any  separate  compiled  object  or  library  files  and  produce  a 
single  object  file  which  can  then  be  loaded  onto  a  transputer  system.  The  support  harness 
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ensures  that  the  application  has  correct  access  to  the  server  running  on  the  host  platform. 
The  problem  which  may  occur  when  linking  a  program  for  execution  on  a  single 
transputer  is  that  of  name  conflict.  For  Ada  programs,  this  problem  can  be  avoided  by 
changing  the  entry  point  name  of  the  program  using  the  Binder  option  ENTRY_POINT. 

3.  Configuring 

Although  the  linker  produces  a  single  object  file,  there  is  still  a  further  step 
required  before  the  program  can  be  executed.  It  is  necessary  to  configure  the  program  to 
prepare  it  for  execution  on  the  target  transputer  system.  Configuratioi  o'  a  single 
transputer  system  involves  adding  bootstrap  code  to  the  program  using  the  iboot  tool.  The 
bootstrap  code  initializes  the  processor,  allocates  workspaces,  loads  the  program  code  and 
finally  invokes  the  program.  A  program  invoked  by  the  bootstrap  loader  should  conform 
to  the  following  specification. 

PROC  main. program  (CHAN  OF  ANY  from. server,  to. server, 

[]INT  workspace,  stack. memory) 

The  from. server  and  to. server  parameters  are  the  channels  used  by  the  host  file 
server  to  boot  the  program  and  may  be  used  for  communication  with  the  server  by  the 
program  when  it  is  running.  The  workspace  and  stack. memory  parameters  are  areas  of 
free  memor\’  for  use  by  the  application  program. 

4.  Loading  and  Running 

The  file  produced  by  ibooi,  which  contains  the  final  executable  program  and 
bootstrap  code,  can  be  loaded  onto  the  target  transputer  using  the  host  file  server,  iserver. 
The  sequence  of  operation  on  a  single  transputer  is  shown  in  Figure  8. 
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Figure  8;  Sequence  of  operation  on  single  trai^puter 


The  following  commands,  provided  in  Makefile,  are  used  to  build  and  run  the 

system  of  Ada  programs.  It  is  assumed  that  the  Ada  programs  have  already  been  compiled 

and  bound  such  that  the  object  code  is  available  in  the  file  "proj.o". 

—  Compile  separate  occam  processes. 

Occam  /s  AS  merger.occ 
Occam  /s  A8  projh.occ 
Occam  /s  A8  projh2.occ 
Occam  /s  A8  main.occ 

—  Fully  link  a  single  step, 
ilink  /f  main.lnk 

-Add  bootstrap  code, 
iboot  main.cSs 

—  Load  and  run  the  program, 
iserver  /sb  main.bSs 
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B.  HOST  TRANSPUTER 


1.  General  Idea 

In  the  combat  system,  during  target  engagement  by  a  high  performance  aircraft 
or  missile,  it  is  critical  that  the  man/machine  interface  by  kept  very  simple.  The  display 
should  provide  sufficient  information  with  low  complexity.  Thus,  the  designed  host 
transputer  should  perform  the  communication  between  the  network  of  transputers  and  the 
PC.  The  system  communicates  with  the  operator  by  keyboard  and  the  monitor  screen. 

2.  The  Transputer  /  PC  Host  development  relationship 

The  transputer  is  normally  employed  as  an  addition  to  an  existing  computer. 


referred  to  as  the  host.  Through  the  host,  the  transputer  application  can  receive  the 
services  of  a  file  store,  a  screen,  and  a  keyboard  as  shown  in  Figure  9. 
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The  transputer  communicates  with  the  PC  host  along  a  single  ENMOS  link.  A 
program,  called  a  server,  executes  on  the  host  at  the  same  time  as  the  program  on  the 
transputer  network  is  run.  All  communications  between  the  application  running  on  the 
transputer  and  the  PC  host  services  (screen,  keyboard  and  filing  resources)  take  the  form 
of  messages.  Software  written  with  the  Occam  toolset  and  Alsys-Ada  compiler,  to  use  the 
standard  INMOS  servers,  assumes  master  status  in  a  master/slave  relationship  between  the 
transputer  and  PC  host.  In  this  situation,  messages  are  always  initiated  by  the  transputer 
system.  The  root  transputer  in  a  network  is  the  transputer  connecting  to  the  host  bus  via 
the  link  adapter  as  described  in  Chapter  11. 

3.  The  Development 

The  main  objective  of  the  Host  transputer  is  to  communicate  with  the  PC  Host. 


This  section  considers  the  simplest  porting  situation  for  an  application.  Before  the  porting 
to  transputer  the  application  look  like  Figure  10. 


Figure  10:  The  starting  point 
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No  assumptions  are  made  about  the  nature  and  capabilities  of  the  original 
compute  engine,  except  that  the  application  uses  only  keyboard,  screen  and  file  system 
through  standard  function  calls  to  the  language’s  run-time  library. 

When  poning  to  transputer  the  application  is  to  be  lifted  from  an  arbitrary 
computer  system,  and  executed  on  a  single  transputer  connected  to  a  supported  host 
platform  as  shown  in  Figure  11. 


Figure  11:  The  entire  application  on  single  transputer 

The  PC  Host  runs  a  simple  program  called  "server”  which  ensures  that  the 
access  requirements  of  the  application  in  terms  of  keyboard,  screen,  and  filing,  are  fully 
satisfied.  The  Occam  2  toolsets  use  a  server  called  iserver.  The  ffom.serv'er  and  to.serv'er 
parameters  are  the  channels  used  by  the  host  file  server  to  boot  the  program  and  may  be 
used  for  communication  with  the  server  by  the  program  when  it  is  running.  This  server 
is  not  recommended  for  use  with  application  port.  The  program  that  controls  this 
operation  is  in  the  file  main.occ  in  APPENDIX  H. 
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C.  TARGET  TRACKER  SUBSYSTEM 
I.  General  Idea 

In  the  Navy’s  Aegis  combat  systems,  a  complex  real-time  radar  surveillance 

system  that  keeps  track  of  target  position,  should  have  a  software  that  supports  this 

operation,  package  PLANE_TRACKER.  It  should  be  able  to  handle  up  to  512  planes  at 

a  time  and  provide  subprogram  to  query  and  update  plane  positions  and  velocities.  Every 

time  a  new  plane  is  detected  by  radar,  PLANE_TRACKER  is  instructed  to  start  tracking 

the  plane.  It  is  also  informed  when  to  discontinue  the  tracking  and  should  raise  exceptions 

when  it  cannot  handle  anymore  planes  or  when  an  untracked  plane  is  referenced.  The 

specification  of  a  package  that  is  able  to  handle  all  the  requirement  above  is: 

with  CALENDAR; 
package  PLANE_TRACKER  is 

MAX_PLANE  :  constant  :=  512; 
type  MILES  is  new  FLO.AT; 
type  MILES_PER_H0L:R  is  new  FLOAT; 
type  PLANE_INFO  is  record 

X.Y.Z  ;  MILES; 

VX.VY.VZ  :  MILES_PER_H0UR; 

T  ;  CALENDAR.TLME; 
end  record; 

type  PLANE_ID  is  limited  private; 

procedure  CREATE_PLANE  (EPLANEJNFO;  ID.out  PLANE_ID); 
procedure  REMOVE_PLANE  (ID:in  out  PLANE_1D); 
procedure  UPDATE_PLANE  (ID:PLANE_ID;  I;PLANE_INFO); 
function  READ_PLANE  (ID;PLANE_1D)  return  PLANE JNEO; 

ILLEGAL, PLANE,TOO_M AN Y_PLANES  :  exception; 
private 

type  PLANE_ID  is  new  INTEGER; 
end  PLANE_TRACKER; 
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2.  The  Tracked  Data  Simulation 


In  principle  radar  system,  the  procedure  of  track  radar  is  that  the  transmitter 
sends  the  electromagnetic  energy  to  the  target  and  the  receiver  receives  the  echo  from  that 
target.  The  echo  information  contains  the  positions  and  velocities  of  the  target.  The 
processing  of  the  echo  infomiation  gives  range  and  direction  of  the  target.  Due  to  this 
principle  the  tracked  data  simulation  should  simulate  the  echo  information. 

In  order  to  simulate  the  tracked  data  which  is  required  for  the  Prediction 
Subsystem,  the  target  trajectory  approximation  that  keeps  updating  the  new  position  of 
the  target  is  selected.  First,  by  mathematics,  the  comparison  between  Trapezoidal  rule  and 
Simpson's  rule  of  integration  has  been  investigated. 

a.  Trapezoidal  Rule 

For  any  trajectory  aLng  function  y  =  f(x)  from  point  a  to  b.  the  positions 
in  the  interval  [a.b]  can  be  approximated  by  the  sum  of  the  trapezoids.  By  dividing  the 
interval  la.b]  into  subintervals  of  equal  length  a  x  =  (b-a)/n  and  denote  the  end  point  of 
the  subintersal  by  a  =  x,,  <  x,  <  x,  <  ...  <  x„  =  b  then 

f^Ax)dx  ■»  ^ 

J  a  n 

and  the  error  for  the  Trapezoidal  Rule  is 

M  . 

I2n^ 

where  M  is  the  maximum  value  of  |r'(x)|  on  the  interval  fa,b] 


b.  Simpson’s  Rule 

The  Simpson’s  rule  uses  parabolic  arcs  rather  than  line  segments.  By 
dividing  the  interval  [a,b]  into  n  subinterval  (n  must  be  an  even  integer)  with  ax  =  (b-a)/n 
and  denote  the  endpoints  Xq  =  a,  Xj  =  a  +  ax,  X2  =  a  +  2ax,  ...  ,  =  a  +  nAX  =  b  then 

and  the  error  for  the  Simpson’s  Rule  is 

i.i . 

180/1* 

where  M  is  the  maximum  value  of  |f''’(x)|,  the  fourth  derivative,  on  the  interval  [a,bl 

c.  The  method  of  simulation 

The  Ada  code  in  APPENDIX  A  computes  the  aircraft  locations  by  using 
I  rapezoidal  rule  and  Simpson’s  rule  of  integration.  It  compares  the  results  with  the 
observed  long-range  radar  location  and  computes  error  values  for  each  integration  method. 
This  program  assumes  that  the  aircraft  flies  back  and  forth  from  the  position  X  =  5000 
m,  Y  =  0  m  to  the  position  X  =  0  m,  Y  =  5000  m  at  the  altitude  of  4000  m.  Time  of 
flight  is  .10  second.  The  function  TRAPEZOIDAL  and  SIMPSON  in  this  program  perform 
the  numeric  calculation  using  Trapezoidal  rule  and  Simpson’s  rule  respectively.  Output 
of  this  program  shows  that  the  position  errors  of  using  Simpson’s  rule  are  always  almost 
zero  when  compare  with  the  errors  of  using  Trapezoidal  rule.  This  leads  to  desire  to  use 
Simpson's  rule  to  simulate  the  tracked  data  rather  than  Trapezoid  rule  because  it  produces 
more  accurate  simulated  data. 
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3.  Tracked  Data 


The  Ada  code  in  APPENDIX  B  produces  the  simulated  tracked  positions  of 
the  target  in  three  dimensions  every  one  second.  In  real  world,  the  target  also  has  the 
velocities  in  three  dimension  and  those  velocities  can  be  changed  all  the  time  because  of 
the  gravity,  wind  speed,  etc.  In  this  program  assumed  that  the  target  approaches  with 
acceleration  until  it  reaches  its  maximum  speed,  and  then  all  the  velocities  remain 
constant.  The  output  shows  the  positions  and  velocities  of  the  target  every  second. 

Since  the  Prediction  Subsystem  required  the  three  dimensional  data  at  least 
seven  previous  position  values,  the  simulation  of  tracked  data  should  produce  the  three 
dimensional  position  data  and  send  the  seven  vectors  of  the  three  dimensional  position 
values  to  the  Prediction  Subsystem  in  the  same  time.  And  also  in  order  to  keep  updating 
the  prediction  it  should  send  the  array  of  data  that  updates  the  new  value  of  tracked  data 
ever)’  second  to  the  Prediction  Subsystem.  Now  the  output  of  the  Target  Tracker 
Subsystem  in  APPENDIX  B  is  not  sufficient  to  meet  this  requirement.  The  Prediction 
Subsystem  needs  only  the  position  values  and  it  needs  seven  previous  values  in  each 
dimension  every  second.  By  modifying  the  code  in  APPENDIX  B,  the  first  seven  outputs 
are  collected  and  send  out  in  form  of  array  in  the  same  time.  When  the  newest  simulated 
data  is  produced  it  will  update  the  value  in  the  array  as  shown  in  APPENDIX  C. 

The  Ada  code  in  APPENDIX  C  shows  the  output  of  simulated  data,  but  before 
running  the  Target  Tracker  Subsystem  in  the  transputer  network  the  only  thing  has  to  be 
modified  is  the  output.  In  stead  of  printing  out,  just  send  these  data  to  Prediction 
Subsystem  using  transputer  communication  links. 
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D.  TARGET  PREDICTION  SUBSYSTEM 


When  the  Tracker  Subsystem  keeps  tracking  the  target  and  updates  every  one 
second,  we  want  at  least  seven  target’s  previous  positions  (Xo,yo,Zo),(x,,y,,z,),...,(x6,y6,Z6) 
to  predict  the  future  position  of  the  target  by  using  the  Least  Square  Orthogonal 
Polynomial  to  fit  the  path  line  of  the  target  in  the  sense  that  the  sum  of  the  square  of  the 
distance  from  the  curve  orthogonal  to  each  plane  position  is  a  minimum. 

The  special  case  of  the  estimation  of  linear  parameters  uses  a  linear  combination 
of  orthogonal  polynomials  to  fit  a  smooth  curv'e  to  a  set  of  points  with  evenly  spaced 
abscissas.  A  set  of  orthogonal  polynomials  commonly  used  for  this  purpose  are  the 
discrete  Legendre  Polynomial  Okj,(t),  which  satisfy  the  orthogonal  relation 


One  form  of  the  discrete  Legendre  Polynomials  for  the  evenly  time-spaced  abscissas 
t  =  0,l,2,...,n  is  a  set  of  0^(t).  The  general  formula  for  the  kth-degree  (k  <  n)  discrete 
Legendre  Polynomial  is 


where  the  binomial  coefficient 


f'l  = 

lyj  y!  ik-jy. 

=  t(t-I)(t-2)...(t-j+l).  r  =  / 

=  n(n-]  }(n-2)...(n-j+] ),  =  I 
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It  is  important  to  note  that  t  has  only  integer  value  0,l,2,...,n-  So,  a  general  form  of 


O^Jt)  are  enumerated  below 

-  1 

n 

O^io  =  1 -6(-?^)-6(-)(-t4) 

n  n  n-\ 

03„(r)  =  1-12(-^).30(-)(14)-20(-)(-^)(-^) 

n  n  n-l  n  n-1  n-2 


By  using  seven  previous  positions  (i.e.  from  time  t  =  0  to  t  =  6)  of  the  target  from 
the  Tracker  Subsystem,  so  t  =  0,1 ,2, 3, 4. 3,6  and  n  =  6.  Therefore,  the  value  of  the  first 
four  Legendre  Polynomial  Oj^t,(t)  are  given  in  table  below. 
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Another  useful  property  of  the  discrete  Legendre  Polynomials  is  the  following  : 


where  (n+k)'"^  =  (n+k)(n+k-l)...(n+l) 

(n)'^'‘*  =  n(n-l)(n-2)...(n-k+l) 

By  setting  fj.(t)  =  0,^(t)  ir  expression  above,  we  obtain  linear  combination  of  the 
Legendre  Polynomial  of  the  form 

FID  =  a^OoJO  +  OiOiJt)  +  a.O.Jt)  +  ...  +  a„OJt) 

And  residuals,  Q,  are  defined  by  the  relation 


r,  =  FiD  -  y,  (I  =  O.n) 

Therefore,  the  coefficient  a,,,  a, . a„  are  determined  such  that  the  sum  of  squared 

residuals  Q  =  S  r,'  X  [Ftt)  -  y,|‘  is  minimized 

The  normal  equations  obtained  by  setting  the  partial  derivative  dQlda^  -  0Q/5a,  = 
.  =  =  0.  reduce  to  the  fomi 


EOoVo  0 

l-Q 

0 

to 

0  Eo?„(0.. 

0 

= 

E  oj'>y. 

r=0 

0  0  .  . 

toLu) 

* 

to„„(0y, 

to 
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Because  of  the  orthogonal  property  the  coefficient  ai.(k=0,m)  which  produce  the 
minimum  Q  are  the  solutions  of  the  normal  equations  aoove  ;  these  solutions  are  : 


t=0 


{k-  0,m) 


To  evaluate  the  unknown  function  at  points  other  than  the  mesh  points,  each 
orthogonal  po'ynomial  of  the  linear  combination,  F(t)  =  a^Ou^Ct)  +  a,0,n(t)  +  a^^Oj^Ct)  + 
...  +  a,„0„,„(t)  is  replaced  by  its  power  of  t  representation,  giving 

f(0  =  ao[l]  -ajl  -2(-^)]  -6(-)  -6-^-^]  ^ 

n  n  n  (n-\) 

Therefore,  the  time  dependent  function  that  approximate  the  path  line  of  the  target 
separately  in  three  dimension  is  introduced,  X(t),  Y(t)  and  Z(t). 

The  Ada  code  in  APPENDIX  D  performs  the  Prediction  Subsystem.  This 
program  requires  seven  inputs  of  position  value  in  each  dimension  which  come  from  the 
Target  Tracker  Subsystem  via  transputer  communication  link  and  produces  the  orthogonal 
coefficients.  P'unction  ORTHOGONAL  performs  the  numeric  calculation  of  orthogonal 
Polynomial  and  function  COEFF_CAL  performs  the  calculation  of  the  coefficient  a^,,  a,, 
and  a.  that  satisfied  the  sum  of  residuals  square  is  minimized.  Now  we  can  fit  the  path 
line  of  the  target  with  the  Polynomial  of  order  2  and  can  predict  the  future  positions  of 
tlie  tareet  at  anvtime  t. 
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E.  BALLISTIC  INTERCEPTION  SUBSYSTEM 


The  predicted  path  line  of  the  target  is  sent  from  the  Target  Prediction  Subsystem 
in  term  of  the  position  function  depend  on  time  in  three  dimension  are 
X(t}  =  +  a,t  +  <32^ 

Y(t)  -  bo  +  bit  +  b2t^ 

Z(i)  =  Co  +  C//  + 

The  actual  values  which  are  sent  through  the  transputer  link  are  just  the  value  of 
the  coefficient  (at„a,,a2),  (bo,b,,b2)  and  (Co,C|,C2).  The  main  objective  of  the  Ballistic 
Interception  Subsystem  is  to  compute  the  interception  time. 

1.  Distance  to  the  target 

Since  the  Interception  Subsysw.w  receives  the  coefficient  values  from  the 
Prediction  Subsystem,  the  first  value  is  the  constant  coefficient  of  the  polynomial,  the 
second  value  is  the  coefficient  of  the  polynomial  first  order  and  the  third  value  is  the 
coefficient  of  the  polynomial  second  order.  The  distance  in  each  direction  at  any  time  t 
is  known  by  substituting  value  of  actual  time  t  in  the  form 
X(t-t)  =  Go  +  a,t  + 

Y(i-t)  -  bg  bjt  +  b.r 
Z(t=l)  =  Cfl  +  c,t  +  C2t 

And  the  overall  actual  distance  to  the  target  at  time  t  is 
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2.  Interception  Time 

The  time  calculation  is  simply  that  time  equal  to  distance  divided  by  speed. 
Also  the  interception  time  equal  to  the  distance  to  the  intercept  point  divided  by  speed 
of  the  ammunition.  The  interception  time  is  the  actual  time  when  target  was  detected  plus 
the  time  required  for  the  bullet  to  go  to  interception  point.  So,  the  interception  distance 
in  each  direction  is  known  by  substitute  the  value  of  t  with  t  =  t+t,of 
X(t=t+t„j)  =  +  at(t+hof)  + 

=  bo  +  +  b2(t+i,,/ 

Z(t=t+t,,f)  =  Co  +  +  C2(t+t,/ 

And  the  overall  interception  distance  at  time  t+tj^f  to  the  target  is 

In  this  thesis  assume  that  the  speed  of  the  ammunition  is  constant  equal  to 
2000  m/sec,  and  also  assume  that  the  trajectory  of  the  bullet  is  the  straight  line.  Therefore, 
the  interception  time  is  known  by  interception  distance  divided  by  2000. 

F.  HOT  SPARE 

1.  Fault  Tolerance 

It  is  not  just  desirable,  but  often  essential,  to  support  both  safety  (guarantee  of 
not  happening)  properties  and  reliability  (guarantee  of  happening)  properties.  Since  system 
elements  may  fail,  it  is  important  to  support  the  tolerance  of  such  failures  in  both  safety 
and  reliability  objectives.  Fault  tolerance  deals  with  handling  faults  by  restoring  either  full 
or  reduced  capability.  Faults  may  have  been  foreseen  but  are  not  desired  or  controlled. 
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They  may  occur  in  any  combination  at  unpredictable  times  and  may  require  quick 
recovery,  particularly  in  the  real-time  Combat  Systems.  Even  if  fault  avoidance  techniques 
applied  in  the  designed  phase  can  reduce  the  probability  of  faults  but  never  eradicate 
them.  Consequently  there  is  the  need  to  tolerate  hardware  faults  during  run-time  so  as  to 
continue  execution  and  preserve  data  integrity. 

a.  Hardware  fault  tolerance 

Hardware  faults  vary'  in  scale  and  duration,  from  transient  memory  faults 
to  the  failure  of  multi-processor  node.  Recovery  from  faults  may  be  based  on  reloading 
and  restarting  lost  processes.  As  parts  of  the  system  fail  it  may  become  unable  to  satisfy 
all  the  requirements  of  the  application.  Techniques  for  graceful  degradation  may  be  very 
useful  to  ensure  that  critical  activities  do  not  fail.  Graceful  degradation  deals  generally 
with  reduced  capability.  When  the  system  has  a  graceful  degradation  capability,  its 
downtime  for  repair  is  shon,  uninterrupted  operation  is  longer,  unavailability  periods  are 
short,  and  overall  processing  power  is  not  seriously  affected  by  failure.  In  a  multi 
processor  system,  graceful  degradation  can  be  achieved  by  re-configuring  the  system: 
switching  out  the  faulty  hardware  or  software  and  switching  in  the  assumed  good 
hardware  or  software,  or  masking  the  fail  item:  not  using  faulty  hardw-are  or  software. 

b.  Software  error  tolerance 

Software  errors  may  be  the  result  of  residual  design  faults.  Ada  was 
designed  to  reduce  residual  design  errors  by  encouraging  highly  modular  and  itructured 
software  design  through  the  use  of  functional  decomposition,  information  hiding  and 
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strong  type  checking.  Nevertheless  software  errors  will  occur  in  Ada  programs.  As  with 
faults,  error  must  be  tolerated  during  run-time.  The  main  requirements  are  similar,  namely 
to  continue  execution,  to  preserve  data  integrity  and  to  prevent  the  propagation  of 
erroneous  results.  Two  main  techniques  have  been  developed  for  software  error  tolerance, 
where  errors  are  assumed  to  arise  from  design  mistake,  recovery  blocks  (Randell  1975) 
and  N-Version  programming  (Chen  &  Avizienis  1978).  These  techniques  are  concerned 
with  sequential  programs  and  so  are  not  effected  by  the  organization  of  distributed  Ada 
programs  as  communicating  sequential  processes. 

2.  Small  Tactical  System  Fault  Tolerance 

Any  system  using  more  than  one  processor  can  have  a  fault-tolerant  feature. 
This  thesis  concerns  only  the  hardware  fault  tolerance.  In  the  designed  Small  Tactical 
System  one  of  the  T8C'J  20  Mhz  transputer  in  the  network  is  used  to  support  the  tolerance 
of  such  failures  in  the  system.  There  are  two  cases  of  system  failure  that  can  occur 
frequently,  loss  of  communication  and  transputer  failure. 

a.  I  OSS  of  communication 

The  network  of  transputer  whose  links  are  connected  through  two  crossbar 
switches.  The  links  can  be  removed  and/or  inserted  while  the  system  is  running.  When 
the  link  is  removed,  the  system  looks  for  another  link  between  the  transputers  that  need 
to  communicate  and  sets  the  crossbar  switches  to  facilitate  the  needed  communication. 
Thus,  the  fixed  communication  links  are  able  to  be  replaced  v  dh  dynamically  assigned 
links  for  direct  communication  between  transputers.  These  crossbar  switches  are 


controlled  by  a  single  transputer  that  takes  communication  requirements  from  each  of  the 
other  transputers  in  the  system. 

b.  Transputer  Failure 

If  an  entire  transputer  node  is  fail,  then  every  task  that  was  executing  on 
that  node  will  have  to  be  restarted.  For  each  task  to  be  restarted,  it  is  necessary  to  recover 
the  data  of  that  task  from  some  other  transputer  node.  In  the  designed  network  of  Small 
Tactical  System,  when  one  of  the  transputers  in  the  network  fails,  one  of  transputer  in  the 
network,  the  HOT  SPARE,  should  reload  the  software  of  the  failed  transputer  and 
perfomts  the  same  operations  as  the  failed  transputer. 
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IV.  SMALL  TACTICAL  SYSTEM  DEVELOPMENT 


A.  GENERAL 

This  chapter  describes  how  to  design  and  develop  an  Ada  system  for  multi¬ 
transputer  network  as  an  efficient  set  of  communicating  programs  with  respect  the  data 
communicated  between  the  programs  especially  the  set  of  floating  point  number.  The 
goals  are  to  develop  the  Ada  programs  that  perform  difference  task  and  run  separately  on 
each  processor,  which  sent  the  computed  data  to  the  other  programs.  Specific  details 
concerning  the  use  of  occam  harness  for  the  set  of  programs  on  each  processor,  and 
configuration  descriptions  for  the  icon/  tool  in  the  Occam  2  toolset. 

B.  MULTI-TRANSPUTER  SYSTEMS 

The  Small  Tactical  System  can  be  modelled  by  placing  the  different  Ada  program 
represented  the  task  of  each  subsystem  onto  each  transputer  of  the  designed  transputer 
network.  The  general  idea  of  multi-transputer  systems  should  be  considered. 

The  main  issue  in  the  design  of  multi-transputer  systems  is  that  of  configuration: 
the  allocation  of  processes  to  a  network  of  interconnected  processors.  Currently,  the  only 
possible  distribution  is  static  distribution;  there  is  no  explicit  support  provided  in  the 
Occam  2  Toolset  for  the  dynamic  allocation  of  processes  to  processors. 

Since  an  Ada  program  may  be  considered  as  a  process,  Ada  programs  may  al.so  be 
distributed  using  the  configuration  tools  supplied  with  the  Occam  2  Toolset. 
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To  implement  an  application  on  a  five  transputer  network,  involves  four  logical 
steps:  Source  Compilation,  Object  linking.  Configuring,  Loading  and  running. 

1.  Source  Compilation 

a.  Source  of  Occam  Harness 

For  multi-transputer  systems,  the  task  of  configuration  is  greatly 
simplified  if  a  harness  is  supplied  for  each  processor.  A  major  advantage  of  this  form  of 
harness  structure  is  that  the  program  to  be  run  on  each  transputer  is  given  a  clean  channel 
interface;  the  parameters  of  each  harness  are  channels  which  will  eventually  be  mapped 
onto  physical  links.  Since  the  network  is  connected  to  host  transputer  using  only  a  single 
link,  The  PROJO  program  is  allocated  to  the  rotn  processor,  the  PROJl,  PROJ2,  PROJ3 
and  PROJ4  programs  are  allocated  to  the  remote  processors.  The  main  harness  is  used  to 
invoke  PROJO  program  and  deal  with  communication  with  the  host.  Source  of  the  Occam 
harness  must  have  the  extension  ".occ". 

b.  Source  of  Ada  Programs 

Single  Ada  programs  cannot  be  distributed  across  a  network;  all  tasks  in 
the  program  execute  on  the  same  transputer.  However,  tasks  in  independent  Ada  programs 
can  communicate  using  transputer  channels  via  the  implementation  defined  package 
CHAN.NELS.  It  is  important  that  all  processes  in  a  transputer  system  complete  their 
application  processing  cleanly.  This  causes  control  to  be  return  to  the  PC  host  operating 
system  and  allows  the  system  to  be  re-run  without  re-booting  the  network  of  transputers. 
The  application  Ada  programs  must  have  the  extension  ”.ada". 
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2.  Object  Linking 

Prior  to  configuration,  all  object  binaries  for  each  processor  must  be  fully 
linked  together.  Linking  is  accomplished  using  the  ilink  tool.  The  linker  is  given  the  name 
of  any  separate  compiled  object  or  library  files  and  produce  the  single  object  file  where 
can  be  loaded  onto  each  transputer  in  the  network. 

3.  Configuring 

Configuration  is  achieved  using  the  iconf  tool  which  takes  a  configuration 
description  and  produces  an  object  file  suitable  for  booting  into  a  network  of  transputers. 
The  purpose  of  the  configuration  description  is  to  allocate  code  to  processors  and  map 
channels  used  in  the  programs  to  physical  links.  The  configuration  description  reflects  the 
physical  interconnection  of  the  processors  in  the  network.  The  root  transputer  is  a  T800 
25  Mhz  which  connected  via  a  single  link  to  a  network  of  2  T800  20  Mhz  processors. 

The  configure  uses  the  configuration  description  to  determine  the  topology  of 
the  network  by  analyzing  the  allocation  of  channels  to  physical  links.  Processor  0  is 
assumed  to  be  the  root  transputer  of  the  network  through  which  the  netw'ork  is  booted. 
There  must  be  a  route  via  transputer  links  from  the  root  transputer  to  all  other  processors 
in  the  network.  The  following  points  should  be  remembered: 

•  All  code  used  in  a  configuration  description  must  be  fully  linked.  There  can  be  no 
explicit  or  implicit  references  to  libraries. 

•  Any  legal  CKcam  code  may  be  written  under  a  PROCESSOR  statement.  However, 
all  code  within  these  statements  must  be  compiled  in  the  same  error  mode  and  for 
the  same  processor  type  as  specified  in  the  PROCESSOR  statement. 
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•  Configuration  channels  must  be  placed  on  an  input  link  on  one  processor  and  an 
output  link  on  another  processor.  Channels  placed  only  once  are  called  dangling 
links;  the  configure  produces  a  warning  if  such  channels  are  used.  Note  that  the 
channels  used  for  communication  with  the  server  are  dangling  links  since  they  are 
placed  only  once  on  the  root  processor. 

•  The  same  separately  compiled  program  may  be  run  on  any  number  of  processors; 
one  copy  of  the  code  exists  in  the  configured  code  and  this  is  loaded  onto  each 
processor  which  requires  it. 

The  default  file  extension  for  configuration  description  is  ".pgm",  the  source 
of  the  configuration  de.scription  in  this  thesis  is  "main. pgm",  provided  in  APPENDIX  F. 
When  configuration  is  completed  a  new  file,  containing  a  bootable  version  of  the  code 
for  the  whole  network,  will  have  been  created.  The  file  have  the  same  name  as  the 
description  source,  but  with  a  ".btl"  extension.  So,  in  this  thesis  it  would  be  "main.btl". 
A  configuration  description  file  with  the  ".dsc"  extension  is  also  created  for  debugger. 

In  order  to  take  advantage  of  fast  internal  memory',  it  is  possible  for  the  main 
harness  on  each  processor  to  control  allocation  of  workspaces  using  the  PLACE 
statement.  Occam  arrays  may  be  stored  in  the  Occam  scalar  or  vector  workspaces  using 
this  mechanism.  The  PLACE  statements  override  the  default  action  of  the  occam  compiler 
which  itself  is  dependent  upon  a  compiler  switch. 

4.  Loading  and  Running 

For  the  multi-transputer  systems,  the  host  file  server  is  used  to  boot  and  load 
a  network  of  transputers.  The  configure  adds  bootstrap  code  to  initialize  each  transputer 
and  route  code  to  the  appropriate  processor.  A  communication  protocol  exists  between  the 
root  transputer  and  a  target  transputer  network  to  direct  the  loading  of  code  to  the  desired 
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place  in  each  transputer.  Provided  the  harness  for  each  processor  is  structured  in  the  same 
way  as  the  default  harness,  a  program  distributed  over  a  network  can  be  restarted. 

The  sequence  of  operation  on  transputer  network  is  shown  in  Figure  12. 


TEST  FAM 


PROJO.ADA 


PROJ1.ADA 


PROJ2.ADA 


PROJ3.ADA 


PRO  J4.  AD  A 


R0J4H2  0C 
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PROJO.O 


bind 

-H 

PROJl.O 

bind, 

PR0J2.0 } 
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PROJ4H.OCC 


PROJ3H.OCC 


3ROJ4H.T8S 
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R0JlH2  0Cd-MPR0JlH2TA> 


ROJ0H2.OCC 
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PROJ4H.M8s} 
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PROJ2H.C8SI- 

. . . 
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AIN.PGM 
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Figure  12:  Sequence  of  operations  on  a  five  transputer  netw’ork 
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C.  TEST  THE  PERFORMANCE  OF  A  5  TRANSPUTER  NETWORK 


Before  placing  the  Ada  program  that  performs  the  task  of  each  subsystem  into  each 
transputer  in  the  network,  the  test  Ada  program  has  been  made  to  ensure  that  all  the 
performance  in  the  network  is  correct.  Each  test  Ada  program  should  have  the  data 
communication  exactly  the  same  as  the  requirement  of  each  subsystem. 

The  main  requirement  of  data  communication  is  to  send  and  receive  the  three 
dimensional  vector, (X,Y,Z),  around  the  network.  The  specific  type  of  data  communication 
is  declared  in  the  package  COMMON  in  the  file  common.ada  in  APPENDIX  G.  The  idea 
of  the  test  program  is  sending  and  receiving  the  three  values  of  floating  point  number  in 
term  of  vector  communication  around  the  transputer  network.  Each  transputer  executes 
the  different  Ada  program.  The  test  network  will  look  like  Figure  13. 


Figure  13:  Test  network  of  transputers 
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Each  transputer  performs  different  task  in  almost  the  same  way.  The  main  procedure 
of  each  program  performs  the  production  its  own  outputs  and  in  the  same  time  performs 
the  communication  in  difference  channel  around  the  network.  The  communication  links 
used  in  the  network  have  to  be  defined  the  name  of  channel. 

1.  Transputer  T4 

T4  is  the  IMS  T800  transputer  in  the  IMS  B003  evaluation  board.  In  this  board 
link3  of  T4  is  connected  to  link2  of  Tj.  T4  executes  the  proj4.ada  which  produces  the 
output  vector  in  three  dimensions  and  sending  these  values  to  T3  through  the 
communication  link3.out  using  the  channel  named  ”Chan". 

2.  Transputer  Tj 

T3  is  the  IMS  T800  transputer  in  the  IMS  B003  evaluation  board.  In  this  board 
link3  of  Tj  is  connected  to  link2  of  Tj.  T3  executes  the  proj3.ada  which  produces  its  own 
outputs,  receiving  the  output  values  of  T4  from  the  communication  link2.in  using  the 
channel  named  "Chan",  passing  these  values  and  sending  its  own  outputs  to  Tj  through 
the  same  communication  link3.out  using  channel  named  "Achan". 

3.  Transputer  Tj 

T;  is  the  IMS  T800  transputer  in  the  IMS  B003  evaluation  board.  In  this  board 
link3  of  T,  is  connected  to  link2  of  T,.  T2  executes  the  proj2.ada  which  produces  its  own 
outputs,  receiving  the  values  from  T,  via  communication  link2.in  using  the  channel  named 
"Achan  ",  passing  the  outputs  of  T4.  T3  and  sending  its  own  outputs  to  T,  through  the  same 
communication  link3.out  using  the  channel  named  "AdaChan". 


4.  Transputer  Tj 

Ti  is  the  IMS  T800  transputer  in  the  IMS  B003  evaluation  board.  In  this  board 
links  of  T,  is  connected  to  link2  of  T4.  LinkO  of  T,  is  connected  to  link2  of  Tq  in  the 
TMB08  TRAM  motherboard.  Tj  executes  the  projl.ada  which  produce  its  own  outputs, 
receiving  the  values  from  Tj  via  communication  link2.in  using  the  channel  named 
"AdaChan  ”,  passing  the  outputs  of  T4,  Tj,  Tj  and  sending  its  own  outputs  to  Tq  through 
the  same  communication  linkO.out  using  the  channel  named  "AdaChannel". 

5.  Transputer  Tj 

Ty  is  the  IMS  T800  2.5  Mhz  in  the  IMS  B417  TRAM  connected  to  PC  using 
the  T.MB()8  motherboard.  Lixik2  of  Ty  is  connected  to  linkO  of  Tj  in  the  BOOS  evaluation 
board.  Ty  executes  the  projO.ada  which  produces  its  own  outputs  after  receiving  the  values 
fiom  T|  via  the  communication  linkO.in  using  channel  named  "AdaChannel".  Ty  performs 
as  the  host  transputer  communicating  with  the  PC  using  the  channel  "from. filer"  and 
"to.filer"  to  take  care  the  print  out  of  all  the  values  passed  from  T4,  T3,  Tj,  T,  and  its  own 
outputs  to  the  screen. 

The  Ada  codes  of  projO,  projl,  proj2,  projS  and  proj4  which  run  on  Ty,  T,,  Tj,  Tj 
and  T4  respectively  are  provided  in  APPENDIX  G.  This  appendix  also  provides  the  output 
and  package  COMMON  in  file  common. ada  which  is  used  to  take  care  the  specific  type 
of  data  communication.  In  this  case,  the  communicated  data  is  the  three  dimensional  array 
of  floating  point  numbers. 
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D.  SMALL  TACTICAL  SYSTEM 


By  the  test  performance  of  5  transputer  network  in  section  C,  the  Small  Tactical 
System  can  be  developed.  The  idea  of  the  Small  Tactical  System  development  is  to  place 
each  subsystem  into  each  transputer  in  the  network  as  shown  in  Figure  14. 


Figure  14:  Modelling  of  Small  Tactical  System 

Therefore,  the  performance  of  each  transputer  in  the  Small  Tactical  System  network 


will  be  as  the  following 

To  executes  the  Host  program. 

T,  executes  the  Interception  Subsystem  program. 

Tj  executes  the  F^rediction  Subsystem  program. 

Tj  executes  the  Target  Tracker  Subsystem  Program. 
T4  executes  the  Hot  Spare  program. 
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Since  the  Interception  Subsystem  and  the  Hot  Spare  have  not  been  developed  yet, 
the  Target  Tracker  Subsystem  and  Prediction  Subsystem  have  been  placed  onto  the 
transputer  Tj  and  Tj  respectively.  The  connection  looks  like  Figure  15. 


AdaChannel 


Figure  15:  Connection  Network 

Due  to  changing  the  network,  they  might  need  to  change  a  little  bit  in  the  programs 
and  reconnected  soft  wires  by  connect  link  2  of  the  T800  25  Mhz  in  the  TMB08  board 
to  link  1  of  the  second  T8(X)  20  Mhz  in  the  B003  evaluation  board.  When  the  new 
connection  has  been  made,  the  output  of  the  check  program  looks  like  below- 
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] 
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The  connection  of  this  network  is  shown  in  Figure  16. 


TMB  08  37  pins  B003  Connector 

D-Type  Connector 


Figure  16:  External  Links 

Now  it  looks  like  three  transputers  network.  Using  two  7800  20  Mhz  on  the  B003 
evaluation  board  and  one  T800  25  Mhz  TRAM  to  simulate  the  performance  of  Small 
Tactical  System  by  placing  the  Ada  program  of  Target  Tracker  Subsystem  in  APPENDIX 
C  onto  transputer  Tj  and  placed  the  Ada  program  of  the  F*rediction  Subsystem  in 
APPENDIX  D  onto  transputer  T,.  The  transputer  Tq  takes  care  of  the  communication  with 
host  PC  and  prints  out  the  output  on  the  screen.  The  performance  of  each  transputer  in 
this  network  is  described  below 
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1.  Transputer  T# 

To  is  the  IMS  T800  25  Mhz  in  the  IMS  B417  TRAM  connected  to  PC  using 
the  TMB08  TRAM  motherboard.  Link2  of  Tq  is  connected  to  linkl  of  T,  in  the  BOOS 
evaluation  board.  Tq  executes  the  projO.ada  which  receives  the  values  from  Tj  via 
communication  link2.in  using  the  channel  named  "AdaChannel”.  Tq  performs  as  the  host 
transputer  communicate  with  the  PC  using  the  channel  "from.filer"  and  "to.filer"  to  take 
care  the  print  out  of  all  the  final  result  ot  the  Small  Tactical  System. 

2.  Transputer  T, 

T;  is  the  IMS  T800  transputer  in  the  IMS  BOOS  evaluation  board.  Linkl  of  T, 
is  connected  to  link2  of  T,,  in  the  TMB08  TRAM  motherboard.  T,  executes  the  pi  .  .ada 
which  is  the  Prediction  Subsystem,  receiving  the  simulated  tracked  data  from  Tj  via 
communication  link2.in  using  the  channel  named  "AdaChan",  and  making  the  calculation 
using  those  values.  It  produces  the  coefficient  values  of  Orthogonal  Polynomial  and  sends 
to  T„  through  the  communication  linkl. out  using  the  channel  named  "AdaChannel". 

3.  Transputer  Tj 

T^  is  the  I.MS  T80()  transputer  in  the  IMS  BOOS  evaluation  board.  LinkS  of  T2 
is  connected  to  link2  of  Tj.  T,  executes  the  proj4.ada  wLich  is  the  Target  Tracker 
Subsystem.  It  produces  the  simulated  tracked  data  vector  in  three  dimensions,  collects 
seven  values  of  data  by  keep  update  the.se  data  every  second  and  sending  these  values  to 
T,  through  the  communication  linkS.out  using  the  channel  named  "AdaChan". 

The  code  of  three  transputers  network  are  provided  in  APPENDIX  H. 


58 


V.  CONCLUSIONS  AND  RECOMMENDATIONS 


A.  CONCLUSIONS 

1.  Ada  on  Transputers  Network 

a.  Alsys-Ada  Compiler 

The  Alsys-Ada  Compiler  includes  a  package  named  CHANNELS  that 
implements  communication  on  transputer  links.  It  defines  relevant  data  types,  and 
procedures  for  channel  I/O. 

b.  Occam  Support 

Ada  code  cannot  be  compiled  to  run  on  the  transputer.  Each  Ada  program 
must  be  supported  with  a  harness  of  Occam.  Other  Occam  programs  (supplied  with  the 
Alsys  distribution)  handle  merging  error  output,  providing  entry  points  to  the  code, 
defining  the  interface  between  the  Ada  procedures  and  the  harnesses,  and  configuring  the 
procedures  for  the  transputer  topology.  The  Ada  and  Occam  objects  are  ultimately  linked 
together  into  single  module,  regardless  of  the  number  of  transputers.  At  run  time,  this 
module  is  decomposed  by  the  Occam  Toolset  iserxcr  and  farmed  out  to  the  topology. 

c.  Issues 

The  limitations  of  running  Ada  programs  on  the  transputer  are  hard  to 
detemiine  owing  to  the  thin  documentation.  Trial  and  error  must  be  employed.  It  is  not 
yet  clear  what  is  the  best  method  for  passing  data  from  Ada  to  Occam  processes.  Occam 
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provides  elegant  mechanisms  for  transmitting  complex  data  structures.  Ada  has  no  such 
utility.  Thus,  the  size  of  the  Ada  run-time  code  means  that  only  one  compiled  Ada 
program  can  be  run  on  a  transputer.  There  is  no  facility  for  compiling  multiple  Ada 
objects  with  a  single  run-time  system. 

2.  Formal  Approach 

This  thesis  is  intended  to  provide  the  first  stage  or  activity  within  the  software 
development  with  Ada  program  on  transputer  by  using  the  Alsys-ada  compiler.  Each 
subsystem  runs  the  Ada  program  on  each  processor  separately  and  at  the  same  time  each 
transputer  sends  the  data  through  the  communication  links  around  the  network.  However, 
not  all  the  goals  could  be  refined  as  necessary.  In  the  same  way  we  do  not  expect  the 
goal  hierarchy  to  be  complete.  Future  refinement  goals,  addition  of  new  subgoals  or 
reorganization  of  the  hierarchy  might  be  necessary  as  knowledge  on  details  in  gained  in 
future  stage  of  development. 

One  big  problem  that  was  found  on  developing  the  Small  Tactical  System  is 
the  Alsys-Ada  Compilation  System.  In  the  complex  Ada  program,  the  data  communication 
among  the  transputers  network  is  difficult,  especially  the  Ada  programs  that  have  the 
concurrency  performance  TASK  by  themselves.  A  lot  of  confusion  in  the  protocols  occurs 
when  the  transputers  communicate  different  types  of  data  through  communication  links. 

The  goal  hierarchy  is  not  yet  completely  defined,  but  the  modelling  of  Small 
Tactical  System  shows  that  the  commercial  VLSI  INMOS  transputer  can  perform  in  the 
same  way  as  the  standard  Navy’s  computer  such  as  an  AN/UYK-7  by  running  the 
software  written  in  the  standard  Department  of  Defence  programming  language,  Ada. 
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B.  RECOMMENDATIONS 


1.  Future  research 

One  of  the  requirement  of  the  AEGIS  combat  system  is  that  the  system  must 
have  Fault  Tolerance  in  the  system  itself.  Since  this  thesis  is  not  dealing  with  this  part 
in  depth,  the  software  development  which  can  detect  all  the  faults  diagnosed  to  one 
transputer  can  be  reloaded  in  healthy  transputers  in  order  to  continue  functioning. 

a.  Commercial  VLSI  Microprocessor 

The  newest  version  of  transputer,  the  INMOS  T9000,  will  be  available 
around  Summer  1992.  The  T9000  is  the  implementation  of  a  superscalar  RISC 
architecture.  It  integrates  a  32  bit  processor,  a  64  bit  floating  point  unit,  16K  bytes  Cache, 
a  communication  processor  and  four  links.  The  T9000  attains  a  peak  performance  of  200 
MIPS,  25  MFLOPS  and  transmission  rates  of  800M  Bits/sec  at  50  Mhz.  The  T9000  is 
software  compatible  with  the  first  generation  of  transputers  and  also  provides  an  improved 
process  and  memory  management.  So,  it  is  obvious  that  the  T9000  has  more  features  than 
the  T805  transputer  and  they  are  software  compatible. 

b.  Real-Time  Operating  System 

One  of  the  drawbacks  in  using  MS-DOS  operating  system  for  developing 
the  Small  Tactical  System  is  that  it  does  not  provide  real-time  mechanisms.  To  make  the 
step  from  the  prototype  to  an  operating  system,  it  is  necessary  to  select  one  of  the 
commercially  available  operating  systems,  which  provide  these  mechanisms  such  as  the 
TRANS-RTXC. 
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c.  Classic-Ada 


Classic-Ada  is  an  extension  to  Ada  that  adds  object-oriented  features  such 
as  class  and  inheritance.  It  supports  standard  Ada  in  its  entirety.  The  Classic-Ada  software 
provides  a  toolset,  most  important  of  which  is  the  Classic-Ada  processor.  The  processor 
converts  programs  written  in  the  Classic-Ada  language  into  standard  Ada.  The  resulting 
Ada  programs  can  then  be  transferred  to  the  PC  and  compiled  using  Alsys-Ada 
compilation  system  for  transputers. 

d.  Man-Machine-Interface 

The  Man-Machine-Interface  which  is  performed  by  the  transputer  Tq  in 
the  transputer  network  will  be  one  of  the  most  complex  modules  within  the  Small  Tactical 
System.  Implementation  of  this  interface  using  commercially  available  software  tools 
should  be  considered.  In  order  to  illustrate  the  simplest  output  and  easy  to  operate  system, 
the  application  should  contain  software  tools  that  include  a  text  editor,  menus,  scroll  bars, 
icons  and  command  buttons. 

2.  Small  Tactical  System  Future  Versions 

In  the  Aegis  combat  system,  there  are  many  sources  of  sensors  that  can 
provide  the  information  of  the  target.  The  Tactical  System  also  requires  the  information 
from  the  Navigational  system  to  calculate  the  accuracy  value  of  interception  time.  Based 
on  the  development  of  Ada  version  on  transputer  network  implementation  of  Small 
Tactical  System,  we  can  provide  some  considerations  on  possible  future  version  which 
can  lead  to  development  of  the  Navy’s  Aegis  combat  system  update. 
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a.  Radar  Interface 

The  network  can  get  the  positional  information  from  the  raw  video 
provided  by  radar  system,  format  it  and  send  it  to  the  Target  Tracker  Subsystem.  The 
Target  Tracker  Subsystem  will  keep  track  that  target. 

b.  Link  11  Interface 

The  network  also  can  get  the  positional  information  from  some  other 
source  on  communication  system  such  as  Link  11.  There  is  a  need  of  an  interface  that 
digitizes  this  information  into  positional  data  and  sends  it  to  Target  Tracker  Subsystem. 

c.  Weapon  System  Interface 

One  of  the  most  important  features  of  a  combat  system  is  the  interface 
to  a  weapons  system.  The  need  for  such  an  interface  is  certainly  dependent  on  the  type 
of  ship.  The  interfaces  should  provide  the  operator  with  the  capability  to  employ  the 
weapon  systems  in  their  various  operational  modes. 
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APPENDIX  A 


Ada  code  that  provides  the  comparison  between  Trapezoid  integration  and 
Simpson’s  integration.  This  program  computes  the  aircraft  location  by  using  Trapezoidal 
rule  and  Simpson’s  rule  of  integration.  It  compares  the  results  with  the  observed  long- 
range  radar.  The  aircraft  assumed  to  fly  back  and  forth  between  two  points  at  altitude  of 
5(XX)  m.  The  output  of  this  lead  to  choose  the  better  method  used  to  simulate  tracked  data 
in  the  Target  Tracker  Subsystem. 
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-  Description  :  This  program  computes  the  aircraft  location  by  using  Trapezoidal  rule 
:  and  Simpson's  rule  of  integration.  It  compares  the  results  with  the 
:  observed  long-range  radars  and  computes  error  values  for  each  method. 


with  TEXT_10,  GENERIC_ELEMENTARY_FUNCTIONS; 
use  TEXT_10; 

procedure  PROJ  is 

package  MATH_FUNCT  is  new  GENERlC_ELEMENTARY_FUNCTIONS(FLOAT); 
use  MATH_FUNCT; 

package  INTEGER_INOUT  is  new  INTEGERJO(INTEGER); 
use  INTEGERJNOUT; 

package  FLOAT_INOUT  is  new  FLOAT_IO(FLOAT); 
use  FLOAT_INOUT; 

type  COMPONENT  is  (X,  Y,  Z); 

type  VECTOR  is  array  (COMPONENT)  of  FLOAT; 

type  VEL_ VALUES  is  array  (0  ..  4)  of  VECTOR; 

DT  :  constant  FLOAT  :=  0.250;  -  delta  time  in  seconds 

XP_T  ;  VECTOR;  -  X  prediction  using  Trapezoidal  integration 

XP_S  :  VECTOR;  -  X  prediction  using  Simpson’s  integration 

XL  :  VECTOR;  —  X  as  observed  from  the  long-range  radar 

T  :  FLOAT  :=  0.0;  —  elapsed  time 

PI  :  constant  FLOAT  ;=  3. 1415_9265_3589_7932_3846_2643  ; 

VEL  :  VEL_V'ALUES;  --  calculated  velocities 

procedure  CALCULATE  VEL(T  :  in  FLOAT;  VEL  :  out  VEL_VALUES)  is 
--  This  prtxredure  CALCULATES  the  VELocity  vectors  of  the  aircraft. 

Cl  ;  constant  FLOAT  :=  5(X).0  *  PI  /  6.0; 

C2  :  constant  FLOAT  :=  PI  /  60.0; 

ANGLE  :  FLOAT; 
begin 

for  1  in  VEL_VALUES'RANGE  loop 
ANGLE  :=  C2  *  (T  +  DT  *  FLOAT(I)); 

VEL(l)  (X)  :=  -  Cl  *  SIN(ANGLE); 

VEL(I)  (Y)  ;=  Cl  *  COS(ANGLE); 

VEL(I)  (Z)  :=  0.0; 

end  loop; 

end  CALCULATE_VEL; 
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function  TRAPEZOID(XPOS:in  VECTOR; VEL;in  VEL_VALUES)  return  VECTOR  is 
T  :  VECTOR; 
begin 

for  I  in  COMPONENT  loop 
T(I)  ;=  0.0; 

for  J  in  VEL_VALUES ’range  loop 
T(I)  :=  T(I)  +  VEL(J)  (I); 
end  loop; 

T(I):=T(I)-(VEL(VEL_VAL1JES’FIRST)(I)+VEL(VEL_VALUES’LAST)(I))  /  2.0; 
T(I)  :=  XPOS(I)  +  DT  *  T(I); 
end  loop; 
return  T; 

end  TRAPEZOID; 

function  SIMPSON(XPOS:in  VECTOR;VEL:in  VEL_VALUES)  return  VECTOR  is 
T  ;  VECTOR; 
begin 

for  I  in  COMPONENT  loop 

T(1):=(VEL(VEL_VALUES’FIRST)(I)+VEL(VEL_VALUES’LAST)(I)); 
for  J  in  VEL_VALUES’F1RST+1..VEL_VALUES’LAST-1  loop 
if  (J  MOD  2)  =  1  then 
T(I)  :=  T(I)  +  4.0*VEL(J)  (I); 
else 

T(I)  ;=  T(I)  ^  2.0*VEL(J)  (I); 
end  if; 
end  loop- 

T(I)  :=  XPOS(l)  +  DT  *  T(l)  /  3,0; 
end  loop; 
return  T; 
end  SIMPSON; 

function  LOCATION(T  :  in  FLOAT)  return  VECTOR  is 
Cl  ;  constant  FLOAT  •=  5000,0; 

C2  ;  constant  FLOAT  :=  PI  /  60.0; 

TT  :  VECTOR; 

ANGLE  :  FLOAT; 
begin 

ANGLE  ;=  C2  *  T; 

rnX)  :=  Cl  *  COS( ANGLE); 

TT(Y)  :=  Cl  *  SIN(ANGLE); 

TT{Z)  :=  4(XX),0; 
return  TT; 
end  LOCATION. 
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function  DIST(VEC_1  :  in  VECTOR;  VEC_2  ;  in  VECTOR)  return  FLOAT  is 

—  This  function  computes  Euclidian  DISTance  between  VEC_1  and  VEC_2 
T  :  FLOAT  :=  0.0; 

begin 

for  I  in  VECTOR ’RANGE  loop 
T  :=  T  +  (VEC_1(I)  -  VEC_2(r))  **  2; 
end  loop; 
return  SQRT(T); 
end  DIST; 

procedure  PRINT(P  ;  in  VECTOR)  is 

-  This  procedure  PRINTS  out  values  of  one  vector 
begin 

PUT(P(X),  FORE  =>  5,  AFT  =>  4,  EXP  =>  0); 

PUT(P(Y),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT(P(Z),  FORE  =>  5,  AFT  =>  0,  EXP  =>  0); 
end  PRINT; 

procedure  PUT_HEADERS  is 

--  This  procedure  PUTs  nice  HE.^DERS  before  the  data  is  printed  out 
begin 

PUTC _ 

NEW_L!NE; 

PUT("  T  I"), 

SET_COL(6): 

PUTC'l.  Trapezoidal  integration"); 

SET_COL(36); 

PL’TC'errors  I"); 

SET_COL(46); 

PUTC’II.  Simpson's  integration"); 

SET_COL(76); 

PUT(  "errors"); 

NE\V_LINE; 

SET_COL(5); 

PUTC  I  "); 

SET_COL(12); 

PUTC'x  y  z  I  I"); 

SET_COL{51);  ” 

PUTC'x  y  z  I"); 

NEWSLINE; 

PLT( " _ 

NEW_LINE; 
end  PUTJIEADERS; 
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begin  —  main  program 


XP_T(X)  :=  5000.0; 

XP_T(Y)  :=  0.0; 

XP_T(Z)  :=  4000.0; 

XP_S(X)  :=  XP_T(X); 

XP_S(Y)  :=  XP_T(Y); 

XP_S(Z)  ;=  XP_T(Z); 

NEW_LINE(2); 

PUT_HEADERS; 
for  I  in  1  ..  20  loop 
for  J  in  1..30  loop 
for  K  in  0..4  loop 
CALCULATE_VEL(T,  VEL); 
end  loop; 

T  ;=  T  +  1.0; 

XP_T  :=  TRAPEZOID(XP_T,  VEL); 

XP_S  ;=  SIMPSON(XP_S,VEL); 
end  loop; 

--  print  out  result.s  at  30  second.s  regular  intervals 
XL  :=  LOCATION(T); 

PUT{INTEGER(T),  WIDTH  =>  3); 

PUT("  I  "); 

PRINT(XP_r); 

PUT("  I  ”); 

PUT(DIST(XP_T,  XL),  FORE  =>  2,  AFT  =>  4,  EXP  =>  0), 
PUT("  I  "); 

SET_COL(44); 

PRINTtXP_S); 

PUT("  I"); 

PUT(D1ST(XP_S,  XL).  FORE  =>  2,  AFT  =>  4,  EXP  =>  0); 
NEW_L1NE; 
end  loop; 
end  PROJ; 
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T  1  I,  Trapezoidal  integration  I  errors  I  II.  Simpson’s  integration  I  errors 
lx  y  z  1  :  X  y  z  I 


301  0.0713  4999.9282  4000.0  10.1013  1 
601-4999.8569  -0.0007  4000.0  I  0.1430  I 
901  0.0722  -4999.9287  4000.0  I  0.1014  I 
1201  4999.9990  0.(XX)5  40(X).0  I  0.0010 

1501  0.0697  4999.9272  4000.0  I  0.1019 

1801-4999.8564  -0.0023  4000.0  I  0.1435 

2101  0.0740  -4999.9287  4000.0  I  0.1(K)4 

2401  4999.9995  0.0021  4000.0  i  0.0006 

2701  0.0684  4999.9277  4(K)0.0  1  0.0996 

3001-4999.8574  -0.0035  4000.0  1  0.1425 

3301  0.0732  -4999.9287  4000.0  I  0.0975 

3601  4999.9985  0.0018  4000.0  1  0.0022 

3901  0.0672  4999.9272  4000.0  I  0.1014 

4201-4999.85^4  -0.0043  40(K).0  I  0.1425 

4501  0.074  2  -4999.9291  4000.0  I  0.1023 

4801  4999.9995  0.0026  4000.0  I  0.0009 

5101  0.0671  4999.9277  4000.0  10.1033 

5401-4999.8569  -0.0043  4000,0  I  0.1431 

5701  0.0756  -4999.9291  4000,0  I  0. 1010 

6001  4999.9995  0.0041  4000.0  I  0.0026 


-0.(XX)3  5000.0004  4000.0  I  0.0005 
-5000.0004  -0.0003  4000.0  i  0.0004 

0.0005  -5000.0000  4000.0  I  0.0005 
5000.0000  0.0010  4000.0  I  0.0001 

-0.0010  4999.9995  4000.0  I  0.0007 
-5000.0000  -0.0016  4000.0  I  0.0015 

0.0013  -5000.0000  4000.0  I  0.0019 
4999.9980  0.0013  4000.0  I  0.0020 

-0.0033  4999.9990  4000.0  I  0.0033 
-5000.0004  -0.0028  4000.0  I  0.0007 

0.0017  -4999.9995  4000.0  1  0.0048 
4999.9995  0.0024  4000.0  I  0.0022 

-0.0038  4999.9995  4000.0  I  0.(XX)6 
-5(XX).0000  -0.0039  40(X).0  I  0.0026 

0.0028  -5000.0009  4000.0  I  0.0026 
4999.9995  0.0025  4000.0  I  0.0010 

-0.(K)44  4999.9990  4000.0  I  0.0024 
-5000.0009  -0.0037  4000.0 ' 0.0035 

0.0030  -4999.9990  4000.0  i  0.0010 
4999.9985  0.0051  4000.0  I  0.0021 
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APPENDIX  B 


Ada  code  for  the  Target  Tracker  Subsystem.  The  objective  of  this  program  is  to 
show  the  simulate  data  which  is  sent  to  the  Prediction  Subsystem.  The  actual  required  of 
the  Prediction  subsystem  is  only  the  positions  of  the  target  in  X,Y  and  Z  direction  but 
output  of  this  program  also  shows  the  velocities  in  three  dimension.  Assume  that  when 
radar  starts  to  track  the  target,  it  approaches  at  some  acceleration  until  reaching  its 
maximum  speed,  and  then  it  approaches  with  constant  velocities.  In  this  case  assume  the 
target  is  a  missile  whose  maximum  speed  is  Mach  3.  The  initial  position  that  is  assumed 
to  be  the  maximum  tracking  range  of  the  radar  (assume  to  be  35  Km.).  The  tracked  data 
simulation  is  terminated  when  the  target  is  too  close  that  the  track  radar  cannot  longer 
keep  track  it  anymore. 

The  first  three  column  of  the  output  is  the  simulated  tracked  data  that  will  send  to 
the  Prediction  Subsystem.  Since  the  Prediction  Subsystem  needs  at  least  seven  positions 
of  the  tracked  data  this  code  will  be  modified  before  put  in  the  network  of  transputers. 
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with  TEXT_IO,  CALENDAR,  GE\ERIC_ELEMENTARY_FUNCTIONS; 
use  TEXTJO,  CALENDAR; 

procedure  PROJ  is 

package  MATH.FUNCTis  new  GENERlC_ELEMENTARY_FUNCTIONS(FLOAT); 
use  MATH_FUNCT; 

package  FLOAT_INOUT  is  new  FLOAT_IO(FLOAT); 
use  FLOATJNOUT; 

—  Type  identifications 

type  COMPONENT  is  (X,Y.Z); 

type  VECTOR  is  array  (COMPONENT)  of  FLOAT; 

type  VELOCITIES  is  array  (0..4)  of  VECTOR; 

DELTA_TIME  :  constant  FLOAT  ;=  0.25;  —  delta  time  t  =  1/4  seconds 


NO_TARGET  :  BOOLEAN  :=  FALSE; 
CURRENT  :  constant  INTEGER  :=  4; 


LINT_SEC 

INTERVAL 

DLSP_TIME 

POSITION 

INT_VEL 

VELOCITY 


:  INTEGER; 

;  DAY_DURATION  :=  1.0; 

:  DAY_DURATION  :=  0.0; 

VECTOR  :=  (27000.0,22000.0,5000.0); 
:  VECTOR  :=  (230.0,180.0,25.0); 

;  VELOCITIES; 


function  "+"(LEFT,  RIGHT  :  in  VECTOR)  return  VECTOR  is 


--  This  function  is  written  to  handle  VECTOR  addition. 


TEMP  :  VECTOR; 
begin 

TEMP(X)  :=  LEFT(X)  +  RIGHT(X); 
TEMP(Y)  ;=  LEFT(Y)  +  RIGHT(Y); 
TEMP(Z)  ;=  LEFTtZ)  +  RIGHT(Z); 
return  TE.MP; 
end 
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function  "-"(LEFT,  RIGHT  :  in  VECTOR)  return  VECTOR  is 


--  This  function  is  written  to  handle  VECTOR  subtraction. 


TEMP  :  VECTOR; 
begin 

TEMP(X)  :=  LEFT(X)  -  RIGHT(X); 

TEMP(Y)  :=  LEFT(Y)  -  RIGHT(Y); 

TEMP(Z)  :=  LEFT(Z)  -  RIGHT(Z); 
return  TEMP; 
end 

function  SIMPSON(XPOS:in  VECTOR;  VEL:in  VELOCITIES)  return  VECTOR  is 


--  This  function  performs  numeric  integration  using  Simpson’s  rule  and  return  a 
--  position  vector  giving  a  set  of  sample  VELOCITIES. 


T  ;  VECTOR; 

I  :  COMPONENT; 

J  :  INTEGER; 
begin 

for  I  in  COMPONENT  loop 

T(I)  :=  (VEL(VELOCITIES’FIRST)  (I)  +  VEL(VELOCITIES’LAST)  (I)); 
for  J  in  VELOCITIES ’FIRST+L.  VELOCITIES ’LAST- 1  loop 
if  (J  MOD  2)  =  1  then 

T(I)  :=  T(I)  4.0*VEL(J)  (I); 
else 

T(l)  :=  T(I)  +  2.0*VEL(J)  (I); 
end  if; 
end  loop; 

T(I)  :=  DELTA_TIME  *  T(l)  /  3.0; 
end  loop; 
return  T; 
end  SIMPSON; 


package  ATOD  is 


--  This  package  is  used  to  maintain  the  velocity  values  for  the  previous 
--  second  at  1/4  second  intervals  (five  \alues).  It  has  one  function 
--  which  returns  an  array  of  five  vector.  The  task  is  written  to  handle 
--  concurrent  processing  of  ACCELEROMETER. 
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procedure  INITIALIZE_VELOCITY{FIRST_VEL  :  in  VECTOR); 
procedure  GET_VELOClTIES(NEW_VEL  :  out  VELOCITIES); 
task  ACCELEROMETER  is 
entry  START; 
end  ACCELEROMETER; 
end  ATOD; 

package  body  ATOD  is 

VEL  :  VELOCITIES  :=  (others  =>  (others  =>  0.0)); 

procedure  INITIALIZE_VELOCITY(FIRST_VEL  :  in  VECTOR)  is 
I  ;  INTEGER; 
begin 

for  I  in  VELOCITIES ’RANGE  loop 
VEL(l)  FIRST_VEL; 
end  loop; 

end  INITIALIZE_VELOClTY; 

procedure  GET_VELOClTlES(NE\V_VEL  :  out  VELOCITIES)  is 
begin 

"nEW_VEL  :=  VEL; 
end  GET_VELOCITlES; 

task  bod>’  ACCELEROMETER  is 
use  CALENDAR; 

INTERVAL  :  constant  DURATION  :=  0.25; 

DISP_TIME  :  DURATION  ;=  0.0; 

LINT_SEC  :  INTEGER  ;=  0; 
begin 

accept  START  do 
null; 

end  START; 

LINT_SEC  :=  INTEGER(SECONDS(CLOCK)); 

DISP_TIME  :=  DURAT10N(LI.NT_SEC); 
while  DISP_TIME  <  SECONDS(CLOCK)  loop 
DISP_TIME  :=  DISP_TIME  +  INTERVAL; 
end  loop; 
loop 

delay  DISP_TIME  -  SECONDS(CLOCK); 
for  {  in  VELOCITIES 'FIRST..  VELOCITIES ’LAST- 1  loop 
VEL(I)  :=  VEL(I+1); 
end  loop; 
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VEL(  VELOCITIES ’LAST)  :=  VEL(VELOCITIES’LAST)+ 

(0.012,0.0098,0.00275); 

exit  when  VEL(4)(X)  >  700.0; 
end  loop; 

end  ACCELEROMETER; 
end  ATOD; 

procedure  PUT_POSITION_ VELOCITY  (XP:  in  VECTOR;  VEL:  in  VECTOR)  is 
begin 

SET_COL(2); 

PUT(XP(X),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT('’  "); 

PUT(XP(Y),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT("  "); 

PUT(XP(Z),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT("  "); 

PUT(VEL(X),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT(”  "); 

PUT(VEL(Y),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT("  "); 

PUT(VEL(Z),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

NEW_LINE; 

end  PUT_POSITION_VELOClTY; 

begin  --  main  program 

ATOD.INITIALIZE_VELOCITY(INT_VEL); 

LINT_SEC  ;=  INTEGER(SECONDS(CLOCK)); 

DISP_TIME  :=  DURAT10N(LINT_SEC)  +  0.8; 
ATOD.ACCELEROMETER.START; 
while  NO_TARGET  =  FALSE  loop 
if  POSlTION\X)  >  0.0  then 

delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
At6d.GET_VELOCIT1ES(VELOCITY); 

PUT_POSITION_VELOCITY(POSmON.VELOClTY(CURRENT)); 
POSITION  :=  POSITION  -  SIMPSON(POSlTION,VELOCITY); 
D1SP_TIME  ;=  DISP_TIME  +  INTERVAL; 
else 

NO_TARGET  :=  TRUE; 
end  if; 
end  loop; 
end  PROJ; 
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Output  of  this  program  shows  that  the  first  12  second  the  target  approaches  with 
some  acceleration  and  when  reaching  its  maximum  speed  it  approaches  with  constant 
velocities.  The  first  3  columns  are  the  positions  and  the  last  3  column  are  the  velocities. 


27000.0000 

22000.0000 

5000.0000 

230.0000 

180.0000 

25.0000 

26770.0000 

21820.0000 

4975.0000 

267.6113 

210.7207 

33.6252 

26502.4121 

21609.2988 

4941.3803 

315.5249 

249.8562 

44.6130 

26186.9101 

21359.4628 

4896.7729 

363.4386 

288.9918 

55.6009 

25823.4960 

21070.4902 

4841.1777 

411.3523 

328.1274 

66.5851 

25412.1679 

20742.3828 

4774.5981 

459.2659 

367.2630 

77.5577 

24952.9257 

20375.1386 

4697.0458 

507.1916 

406.4084 

88.5330 

24445.7578 

19968.7500 

4608.5180 

555.1789 

445.5146 

99.4974 

23890.6035 

19523.2558 

4509.0258 

603.2025 

484.6404 

110.4673 

23287.4257 

19038.6347 

4.398.5639 

651.2020 

523.7832 

121.4316 

22636.2480 

18514.8710 

4277.1376 

699.2015 

563.0112 

132.3960 

21937.0703 

17951.8789 

4144.7470 

700.0071 

563.6696 

132.5800 

21237.0878 

17388.2285 

4012.1726 

700.0071 

563.6696 

132.5800 

20537.1054 

16824.5781 

3879.5981 

700.0071 

563.6696 

132.5800 

19837.1230 

16260.9277 

3747.0236 

700.0071 

563.6696 

132.5800 

19137.1406 

15697.2773 

3614.4492 

700.0071 

563.6696 

132.5800 

18437.1582 

15133.6269 

3481.8747 

700.0071 

563.6696 

132.5800 

17737.1757 

14569.9765 

3.349.3002 

700.0071 

563.6696 

132.5800 

17037.1933 

14006.3261 

3216.7258 

700.0071 

563.6696 

132.5800 

16337.2099 

13442,6757 

.3084.1513 

700.(K)71 

563.6696 

1 32.5800 

15637.2265 

12879.0253 

2951.5769 

700.0071 

563.6696 

132.5800 

14937.2431 

12315.3750 

2819.0024 

700.0071 

563.6696 

132.5800 

14237.259^ 

1  1751.7246 

2686.4279 

7(X).007 1 

563.6696 

132.5800 

13537.2763 

11188.0742 

2553.8535 

700.007 1 

563.6696 

132.5800 

12837.2929 

10624.4238 

2421.2790 

7(X).0071 

563.6696 

132.5800 

12137.3095 

10060.7734 

2288,7045 

700.0071 

563.6696 

132.58(X) 

1 1437.3261 

9497.1230 

2156.1.^01 

7(X)0071 

563.6696 

132.5800 

10737.3427 

8933.4726 

2023.5555 

700.0071 

563.6696 

132.58fX) 

1(X)37.3593 

8369.8222 

1890.9809 

700.(X)71 

563.6696 

132.58(X) 

9337.3759 

7806.1723 

1758.4063 

700.007 1 

563.6696 

132.5800 

8637.3925 

7242.5224 

1625.8317 

700.0071 

563.6696 

132.5800 

7937.4096 

6678.8725 

1493.2572 

700.0071 

563.6696 

132.5800 

72.^7.4267 

6115.2226 

1360.6826 

700.0071 

563.6696 

132.58(X) 

6537.4438 

5551.5727 

1228.1080 

700.0071 

563.6696 

132.5800 
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APPENDIX  C 


Since  the  Prediction  Subsystem  requires  at  least  seven  position  values  in  each 
dimension.  The  Ada  code  in  this  appendix  is  the  modified  code  from  APPENDIX  B  that 
preptu'e  the  output  ready  to  send  to  the  Prediction  Subsystem  in  term  of  array  3*7  of 
floating  point  numbers.  The  output  of  this  program  is  (Xo,Yo,Zo),(X,,Y,,Z,) . (X^.Y^.Z^). 
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-  File:  proj.ada 

with  TEXT_IO,  CALENDAR,  GENERlC_ELEMENTARY_FUNCnONS; 
use  TEXT_10,  CALENDAR; 


prcKedure  PROJ  is 

package  MATH_EUNCT  is  new  GENERIC_ELEMENTARY_FUNCnONS(FLOAT); 
use  MATH_FUNCT; 


package  FLOAT_INOLT  is  new  FLOAT_IO(FLOAT); 
use  FLOAT_INOUT; 


--  Type  identifications 

type  COMPONENT  is  (X,Y,Z); 

type  VECTOR  is  array  (COMPONENT)  of  FLOAT; 

type  VELOCITIES  is  array  (0..4)  of  VECTOR; 

type  ARY_7  is  array  (0..6)  of  VECTOR; 


DELTA_TIME  :  constant  FLOAT  :=  0.25;  -  delta  time  t  =  1/4  seconds 
NO_TARGET  :  BOOLEAN  :=  FALSE; 

CURRENT  :  constant  INTEGER  :=  4; 

LINT_SEC  ;  INTEGER; 

INTERVAL  ;  DAY.DURATION  :=  1.0; 

DISP_TIME  ;  DAY_DURATION  :=  0.0; 

POSITION  :  VECTOR  :=  (27(X)0.0.22(KX).0.5(X)0.0); 
P.r*O.Pl.P2.P.UP4.P5,P6  :  VECTOR  ;=  (O.O.O.O.O.O); 

INT_VEL  ;  VECTOR  :=  ..M).0. 1 80.0,25.0); 

VELOCITY  :  VELOCITIES; 

B  ;  ARY_7  ; 


function  'V"(LEFT.  RIGHT  :  in  VECTOR)  return  VECTOR  is 


--  This  function  is  wntten  to  handle  VECTOR  addition. 


TE.MP  :  VECTOR; 
begin 

TEMP(X)  :=  LEFT(X)  +  RIGHT(X); 
TEMPtY)  :=  LEFT(Y)  +  RIGHT(Y); 
TEMP(Z)  :=  LEFT(Z)  +  RIGHT(Z); 
return  TEMP; 
end  '■+■■; 
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function  "-"(LEFT,  RIGHT  :  in  VECTOR)  return  VECTOR  is 


—  This  function  is  written  to  handle  VECTOR  subtraction. 


TEMP  :  VECTOR; 
begin 

TEMP(X)  :=  LEFT(X)  -  RIGHT(X); 

TEMP(Y)  :=  LEFT(Y)  -  RIGHT(Y); 

TEMP(Z)  :=  LEFT(Z)  -  RIGHT(Z); 
return  TEMP; 
end 

function  SIMPSON(XPOS:  in  VECTOR;  VEL;  in  VELOCITIES)  return  VECTOR  is 


-  This  function  performs  numeric  integration  using  SIMPSONS  rule  and  return  a 

-  position  giving  a  set  of  sample  VELOCITIES,  and  the  DELTA_TIME  between 

-  those  velocities. 


T  :  VECTOR; 

1  :  COMPONENT; 

J  ;  INTEGER; 
begin 

Vor  I  in  COMPONENT  loop 

T(I)  ;=  (VEL(  VELOCITIES ’FIRST)  (I)  VEL(VELOCITIES'LAST)  (I)); 
for  J  in  ViXOCmES’nRST+L.VELOCITIES’LAST-l  loop 
if  (J  MOD  2)  =  1  then 

T(I)  :=  T(I)  +  4.0*VEL(J)  (I); 
else 

T(l)  ;=  T(I)  +  2.0*VEL(J)  (I); 
end  if; 
end  loop; 

T(I;  ;=  DELTA_T1.\1E  *  Til)  /  3.0; 
end  Kxip; 
return  T; 
end  SIMPSON; 


package  ATOD  is 


--  This  package  is  used  to  maintain  the  velocity  values  for  the  previous  second  at  1/4 
--  second  intervals  (five  values).  It  has  one  function  which  returns  an  array  of  five 
--  vector.  The  task  is  written  to  handle  concurrent  processing  of  ACCELEROMETER. 
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procedure  INITIALIZE_VELOCITY(FIRST_VEL  :  in  VECTOR); 
procedure  GET_VELOCITIES(NEW_VEL  :  out  VELOCITIES); 
task  ACCELEROMETER  is 
entry  START; 
end  ACCELEROMETER; 
end  ATOD; 

package  body  ATOD  is 

VEL  :  VELOCITIES  :=  (others  =>  (others  =>  0.0)); 

procedure  INITIALIZE_VELOCITY(FIRST_VEL  :  in  VECTOR)  is 
I  :  INTEGER; 
begin 

^for  I  in  VELOCITIES ’RANGE  loop 
VEL(l)  :=  F1RST_VEL; 
end  loop; 

end  INITIALIZE_VELOCITY; 

procedure  GET_VELOCITIES(NEW_VEL  :  out  VELOCITIES)  is 
begin 

\eW_VEL  :=  VEL; 
end  GET.VELOCITIES; 

task  body  ACCELEROMETER  is 
use  CALENDAR; 

INTERVAL  ;  constant  DURATION  ;=  0.25; 

D1SP_TIME  ;  DURATION  :=  0.0; 

LINT_SEC  ;  INTEGER  ;=  0; 
begin 

accept  START  do 
null; 

end  START; 

LINT_SEC  INTEGER(SECONDS(CLOCK)); 

D1SP_TIME  ;=  DURATION(LINT_SEC); 
while  DISP_TIME  <  SECONDS(CLOCK)  loop 
DISP.TIME  :=  DISP_TIME  +  INTERVAL; 
end  loop; 

Icxip 

delay  DISP_T1ME  -  SECONDS(CLOCK); 
for  I  in  VELOCITIES 'FIRST..  VELOCITIES 'LAST- 1  loop 
VELtn  ;=  VEL(I+1); 
end  kxip; 
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VEL(  VELOCITIES ’LAST)  :=  VEL(VELOCITIES’LAST)  + 

(0.012,0.0098,0.00275); 

exit  when  VEL(4)(X)  >  700.0; 
end  loop; 

end  ACCELEROMETER; 


end  ATOD; 


begin  -  main  program 

ATOD.INITIALIZE_VELOCITY(INT_VEL); 

LINT_SEC  :=  INTEGER(SECONDS(CLOCK)); 

DISP_TIME  :=  DURATION(LINT_SEC)  +  0.8; 
ATOD.ACCELEROMETER.START; 

delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
ATOD.GET_VELOCITIES(VELOCITY); 

P0(X)  :=  POSITION(X); 

P()(Y)  :=  POSITION(Y); 

P()(Z)  ;=  POSmON(Z); 

B(0)(X)  :=  P0(X); 

B(())(Y)  :=  PO(Y); 

B(0)(Z)  ;=  P0(Z); 

POSITION  :=  POSITION  -  SIMPSON(POSITION, VELOCITY); 
DISP_TLME  ;=  DISP.TIME  +  INTERVAL; 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
At6d.GET_VELOCITIES(VELOCITY); 

PKX)  :=  POSITION(X); 

PKY)  :=  POSmON(Y); 

PKZ)  :=  POSITION{Z); 

B(1)(X)  ;=  P1(X); 

B{1)(Y)  :=  P1(Y); 

B(1)(Z)  ;=  P1(Z); 

POSITION  :=  POSITION  -  SIMPSON(POSmON,VELOCITY); 
DISP_TIME  :=  DISP.TIME  +  INTERVAL; 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
At6d.GET_VELOCITIES(VELOCITY); 

P2(X)  .-  POSmON(X); 

P2(Y)  :=  POSmON(Y); 

P2(Z)  :=  POSITION(Z); 
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B(2)(X)  :=  P2(X); 

B(2)(Y)  :=  P2(Y); 

B(2)(Z)  :=  P2(Z); 

POSITION  ;=  POSITION  -  SIMPSON(POSITION,VELOCITY); 
DISP.TIME  :=  DISP_TIME  +  INTERVAL; 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
ATOD.GET_VELOCITIES(VELOClTY); 

P3(X)  :=  POSITION(X); 

P3(Y)  :=  POSmON(Y); 

P3(Z)  ;=  POSITION(Z); 

B(3)(X)  :=  P3(X); 

B(3)(Y)  ;=  P3(Y); 

B(3)(Z)  :=  P3(Z); 

POSITION  ;=  POSITION  -  SIMPSON(POSITION,VELOCITY); 
DISP_TIME  :=  DISP_TIME  +  I.NTERVAL; 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
At6d.GET_VELOCIT1ES(VELOCITY); 

P4(X)  :=  POSITION(X); 

P4(Y)  :=  POSmON(Y); 

P4(Z)  :=  POSITION(Z); 

B(4)(X)  :=  P4(X); 

B(4)(Y)  ;=  P4(Yj; 

B(4)(Z)  :=  P4(Z); 

POSITION  :=  POSITION  -  SIMPSON(POSITION.VELOCITY); 
DISP_TIME  :=  DISP_TIME  +  INTERVAL: 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
At6d.GET_VELOCITIES(VELOC1TY); 

P.^(X)  ;=  POSITION(X); 

P5{Y)  :=  POSITION (Y); 

P.SIZ)  :=  POSITION(Z); 

B(5)(X)  :=  P.'liX); 

B(5)(Y)  :=  P5(Y); 

B(.'i)(Z)  ;=  P5(Z); 

POSITION  :=  POSITION  -  S I MPSON(POSITION, VELOCITY); 
DISP_TIME  :=  DISP_T1ME  +  INTERVAL; 
delay  (D1SP_TIME  -  SECONDS(CLOCK)  -  0.02); 
At6d.GET_VELOCITIES(VELOCITY); 

P6(X)  :=  POSmONIX); 

P6(Y)  ;=  POSmON(Y); 
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P6(Z)  :=  POSITION(Z); 

B(6)(X)  :=  P6(X); 

B(6)(Y)  :=  P6(Y); 

B(6)(Z)  :=  P6(Z); 

POSITION  ;=  POSITION  -  SIMPSON(POSITION,VELOCITY); 
DISP_TIME  :=  DISP_TIME  +  INTERVAL; 
while  NO_TARGET  =  FALSE  loop 
if  POSITION(X)  >  0.0  then 

PUT  (B(0)(X),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(1)(X),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(2)(X),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(3)(X).  FORE  =>  6.  AFT  =>  4,  EXP  =>  0); 

PUT  (B(4)(X),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(5)(X),  FORE  =>  6,  AFT  =>  4,  EXP  ->  0); 

PUT  (B(6)(X),  FORE  =>  6.  AFT  =>  4,  EXP  =>  0); 

NEW_LINE; 

PUT  (B(0)(Y),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(1)(Y),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(2)(Y),  FORE  =>  6,  AFP  4,  EXP  =>  0); 

PUT  (B(3)(Y),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(4)(Y),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(5)(Y),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(6)(Y),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

NEW_LINE; 

PUT  (B(0)(Z).  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(1)(Z),  FORE  =>  6.  AFT  =>  4,  EXP  =>  0); 

PUT  (B(2)(Z),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(3)(Z),  FORE  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(4)(Z),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(3)(Z),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 

PUT  (B(6)(Z),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
NEW_LINE(3); 

delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
At6d.GET_VELOCITIES(VELOC1TY); 

P(X)  :=  POSmON(X); 

P(Y)  ;=  POSITION(Y); 

P(Z)  :=  POSITION(Z); 

POSITION  :=  POSITION  -  SIMPSON(POSITION, VELOCITY); 
DISP_TIME  ;=  DISP_TIME  +  INTERVAL; 
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PO 

PI 

P2 

P3 

P4 

P5 


=  PI 
=  P2 
=  P3 
=  P4 
=  P5 
=  P6 


P6  P; 

B(0)(X) 

=  PO(X) 

B(1)(X) 

=  PKX) 

B(2)(X) 

=  P2(X) 

B(3)(X) 

=  P3(X) 

B(4)(X) 

=  P4(X) 

B(5)(X) 

=  P5(X) 

B(6)(X) 

=  P6(X) 

B(O)fY') 

-  PO(Y) 

B(1)(Y) 

=  P.(Y) 

B(2)(Y) 

=  P2(Y) 

B(3)(Y) 

=  P3(Y) 

BO)(Y) 

=  P4(Y) 

B(3)(Y) 

=  P5(Y) 

B(6)(Y) 

=  P6(Y) 

B(0)(Z) 

=  P0(Z); 

B(1)(Z) 

=  PKZ); 

B(2)(Z) 

=  r2(Z); 

B(3)(Z) 

=  P3(Z); 

B(4)(Z) 

=  P4(Z); 

B(5l(Z) 

=  P5(Z); 

B(6)(Z) 

=  P6(Z); 

else 

NO  TARGET  TRUE 
end  if; 
end  loop; 


end  PROJ; 


APPENDIX  D 

Ada  code  that  provides  the  performance  of  Prediction  Subsystem.  It  needs  at  least 
seven  values  of  position  vector  and  computes  the  Orthogonal  Polynomial  coefficient. 
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-  File:  projl.ada 


with  TEXTJO,  COMMON,  CHANNELS; 
use  TEXTJO,  COMMON; 

procedure  PROJl  is 

B  :  ARY_7; 

RESULT  :  VEC_3; 

TOTAL  :  VEC_3; 

C  :  CHANNELS.CHANNEL_REF  :=  CHANNELS. IN_PARAMETERS  (2); 

D  :  CHANNELS. CHANNEL_REF  :=  CHANNELS .OUT_PARAMETERS  (2); 
--  The  channel  used  for  communication  with  the  program  producing  the  stream. 
—  Input  channels  0  and  1  are  reserved  for  use  by  the  run-time  system. 

package  FLOATJNOUT  is  new  FLOAT_IO(FLOAT); 
use  FLOAT_INOUT; 

”  type  identification 

type  COMPONENT  is  (X0,XLX2,X3,X4,X5,X6); 
type  VECTOR  is  array  (COMPONENT)  of  FLOAT; 
type  POSITIONS  is  array  (0..3)  of  FLOAT; 
type  VEC  is  array  (0..2)  of  FLOAT; 

-  orthogonal  constant 

CONSTO  ;  VECTOR  :=  (1.0, 1.0. 1.0, 1.0, 1.0. 1.0, 1.0); 

CONSTl  :  VECTOR  :=  (1.0,0.666,0.333,0.0,-0.333,-0.666,-1.0); 

CONST2  :  VECTOR  :=  (1.0,0.0,-0.6,-0.8,-0.6,0.0,l.()); 

CONST3  :  VECTOR  :=  (1.0,-1.(),-1.0,0.0,1. 0.1.0,- 1.0); 

T  :  VECTOR  :=  (0.0,0.0,().(),0.0,0.0,0.0,0.0); 

POS  :  POSITIONS  ;=  (().(),().0,0.0,0.0); 

COEF  :  VEC; 

function  VECTOR_SUM  (X  :  VECTOR)  return  FLOAT  is 
SUM  :  FLOAT  :=  0.0; 
begin 

for  I  in  X’RANGE  loop 
SUM  :=  SUM  -t-  X(I); 
end  loop; 
return  SUM; 
end  VECTOR_SUM; 
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function  VECTOR_SUM_SQUARE  (X  :  VECTOR)  return  FLOAT  is 
SUM_SQUARE  :  FLOAT  :=  0.0; 
begin 

for  I  in  X’RANGE  loop 

SUM_SQUARE  :=  SUM_SQUARE  +  (X(I)**2); 
end  loop; 

return  SUM_SQUARE; 
end  VECTOR_SUM_SQUARE; 


function  ORTHOGONAL  (POS_IN  :  VECTOR)  return  POSITIONS  is 
TEMPO, TEMP LTEMP2,TEMP3  :  VECTOR; 
POS_OUTO,POS_OLT1,POS_OUT2,POS_OUT3  :  FLOAT; 

ORTHO  :  POSITIONS; 
begin 

for  I  in  COMPONENT  loop 

TEMPO(I)  :=  POS_IN(l)  *  CONSTO(I); 

TEMPl(I)  ;=  POS_IN(I)  *  CONSTl(I); 

TEMP2(1)  ;=  POS_IN(I)  *  CONST2(l); 

TEMP3(I)  :=  POS_IN(l)  *  CONST3(I); 
end  loop; 

POS.OUTO  :=  VECTOR_SUM(TEMPO)A^ECTOR_SUM_SQUARE(CONSTO) 
POS.OUTl  :=  VECTOR_SUM(TEMPl)A^ECTOR_SUM_SQUARE(CONSTl) 
POS_OUT2  :=  VECTOR_SUM(TEMP2)A^ECTOR_SUM_SQUARE(CONST2) 
POS_OUT3  :=  VECTOR_SUM(TEMP3)ATECTOR_SUM_SQUARE(CONST3) 
ORTHO  :=  (POS_OUTO,POS_OUTLPOS_OUT2,POS_OUT3); 
return  ORTHO; 
end  ORTHOGONAL; 


function  COEFF_CAL  (A  :  in  POSITIONS)  return  VEC  is 
a0,aLa2  :  FLOAT; 

V  ;  VEC; 
begin 

aO  :=  A(0)+A(l)+A(2)+A(3); 

al  :=  (-A(I)*(0.3333))+(A(2)*(-L2))+(-A(3)*(0.6667)); 
a2  :=  (A(2)*(0.2000))+(A(3)*(L500)); 

V  :=  (a0,al,a2); 
return  V; 

end  COEFF_CAL; 
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begin 

loop 

VECTORJO.READ  (C,  RESULT); 
VECTORJO.WRITE  (D,  RESULT); 
exit  when  RESULT(O)  <  0.0; 
ARRAYJO.READ  (C,  B); 

T(X0)  :=  FLOAT(B(0)(0)); 

T(X1)  ;=  FLOAT(B(1)(0)); 

T(X2)  ;=  FLOAT(B(2)(0)); 

T(X3)  :=  FLOAT(B(3)(0)); 

T(X4)  :=  FLOAT(B(4)(0)); 

T(X5)  ;=  FLOAT(B(5)(0)); 

T(X6)  ;=  FLOAT(B(6)(0,)); 

POS  :=  ORTHOGONAL(T); 

COEF  :=  COEFF_CAL(POS); 
TOTAL(O)  :=  FLO_6(COEF(0)); 
TOTAL(l)  :=  FLO_6(COEF(l)); 
TOTAL(2)  ;=  FLO_6(COEF(2)); 
VECTOR_IO.WRITE  (D,  TOTAL); 
end  loop; 


TOTAL(O)  ;=  -1.0; 

VECTORJO.WRITE  (D,  (TOTAL(O),  0.0,  0.0,  0.0)); 


end  PROJl; 
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APPENDIX  E 


For  a  single  transputer  system,  there  are  eight  files  that  are  needed  to  support  the 
operation.  Assume  all  Ada  code  that  will  be  run  on  single  transputer  has  the  main 
procedure  named  PROJ  in  the  file  PROJ.ADA. 

This  appendix  provides  all  code  that  is  necessary'  to  run  our  Ada  program  on  single 
transputer,  which  is  the  following: 

-  makefile 

-  family. inv 

-  proj.inv 

-  main.occ 

-  merger.occ 

-  projh.occ 

-  projh2.occ 

-  main. Ink 
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#  File  :  makefile 


#  "make  help"  to  print  option  list 

#  Complete  de  lopment  cycle; 

#  make  family  —  makes  Ada  family  and  library  directories 

#  make  —  compiles,  links,  configures  source 

#  make  run  -  run  bootable  code 

MODE  =  s 
PROC  =  8 

OPTS  =  /$(MODE)  /t$(PROC) 

#  make  the  executable  code 

main.bS(PROC)$(MODE);  main.c$(PROC)$(MODE) 
iboot  main.c$(PROC)$(MODE) 

@  f:\util\bell 

main.c$(PROC)$(MODE);  proj.o  merger.t$(PROC)$(MODE)  projh.t$(PROC)$(MODE) 
main.tS(PROC)$(MODE) 
ilink  /f  main. Ink 

proj.o;  proj.ada 

ada  invoke  proJ.inv,yes 

merger. t$(PROC)$(MODE);  merger.occ 
Occam  $(OPTS)  merger.occ 

projh.tS(PROC)$(MODE);  projh2.tax  projh.occ 
Occam  $(OPTS)  projh.occ 

projh2.tax;  projh2.occ 

Occam  Aa  /x  projh2.occ 

main.tS(PROOS(MODE);  main.occ 
Occam  $(OPTS)  main.occ 

# 

#  misc. 

# 

help; 

@  echo  Make  arguments; 

@  echo  make  -  make  from  top  level  down 
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@  echo 

make  -n  [opt] 

-  display  but  don’t  execute  commands 

@  echo 

make  proj.o 

-  make  Ada  object 

@  echo 

make  help 

-  display  this  list 

@  echo 

make  clean 

-  delete  all  files  except  source 

@  echo 

make  run 

-  run  bootable  program 

@  echo 

make  check 

-  check  transputer  topology 

@  echo 

make  family 

-  make  Ada  family  and  library  directories 

clean: 

del  *.?8? 
del  *.tax 
del  *.o 

del  proj_lib\adalib.* 
rd  proj_lib 

del  proj_fam\adafam.* 
rd  proj_fam 

run: 

iserver  /sb  main.bSs 

check: 

check  /r 

family: 

ada  invoke  family. inv, yes 


--  File:  family. inv 

family. new  proj_fam.overwrite=yes 
lib(family=proj_fam).new  proj_lib,overwrite=yes 

--  File:  proj.inv 

compile  source=proj.ada,library=proj_lib 

default. bind  library=proj_lib,level=bind,waming=no 

bind  proj,object="proj.o",entry'_point="proj. program" 


#File  :  main.occ 

#0PT10N  "AGNVW" 
#INCLUDE  "hostio.inc" 
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PROC  MAIN.ENTRY  (CHAN  OF  SP  FromFiler,  ToFiler,  [(INT  FreeMemory, 

StackMemory) 

#USE  "hostio.lib” 

#USE  "merger.tSs" 

#USE  "projh.tSs” 

[1]CHAN  OF  ANY  Debug: 
f21CHAN  OF  SP  FromAda,  ToAda: 

CHAN  OF  BOOL  StopDebug,  StopMultiplexor: 

WHILE  TRUE 
SEQ 

PAR 

--  A  multiplexor  to  combine  the  debug  and  normal  output. 

so. multiplexor  (FromFiler,  ToFiler,  FromAda,  ToAda,  StopMultiplexor) 

-  A  debug  channel  merger. 

debug. merger  (ToAda[{)l,  FromAda[0].  Debug,  StopDebug) 

--  A  process  to  invoke  the  Ada  programs. 

SEQ 

PAR 

(5()(X)0]  INT  ws: 

proj. harness  (FromAda[ll,  ToAda[l],  Debug[0],  ws) 

StopDebug  !  FALSE 
StopMultiplexor  !  FALSE 

so.exit  (FromFiler,  ToFiler,  sps. success) 
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#  File:  merger.occ 


#OPTION  "AGNVW" 

#INCLUDE  "hostio.inc" 

PROC  debug.merger  (CHAN  OF  SP  FroniFiler,  ToFiler, 
[]CHAN  OF  ANY  Debug, 

CHAN  OF  BOOL  Stop) 

#USE  "hostio.lib" 

-  A  debug  channel  merger  and  blocker. 

VAL  max. debug  IS  20: 

VAL  number.of.debug  IS  SIZE  Debug: 

INT  line. index: 

[256] BYTE  line.buffer: 

BYTE  value,  r: 

BOOL  running,  reset,  s: 
fmax.debug]BOOL  mask: 

VAL  BYTE  line.feed  IS  10  (BYTE): 

SEQ 

SEQ  i  =  0  FOR  number.of.debug 
maskiij  :=  TRUE 
running  :=  TRUE 
reset  :=  FALSE 
line. index  ;=  0 
WHILE  running 
PRI  ALT 

ALT  i  =  0  FOR  number.of.debug 
mask[i]  &  Debug[i|  ?  value 
SEQ 
IF 

value  =  line.feed 
SEQ 

—  Send  the  complete  line, 
so. puts  (FromFiler,  ToFiler,  spid.stdout, 
[line.buffer  FROM  0  FOR  line. index],  r) 
line. index  :=  0 
mask  [i]  :=  FALSE 
reset  :=  TRUE 
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TRUE 

SEQ 

—  Add  character  to  line, 
line. buffer[]ine. index]  :=  value 
line. index  :=  line. index  +  1 
reset  &  SKIP 


SEQ 

reset  :=  FALSE 

SEQ  i  =  0  FOR  number.of.debug 
mask[i]  :=  TRUE 
Stop  ?  s 

running  :=  FALSE 


--  File;  main. Ink 
--  Purpose:  File  list  for  ilink 
main.tSs 
merger.tSs 
hostio.lib 
occamHs.lib 

(  projh.tSs  proj.o  adartsS.lib  hostio.lib  occamSs.lib  ) 


#  File:  projh2.occ 
#OPTION  "ACV  " 

PROC  proj. program  ([|INT  wsl,  in,  out,  ws2) 
[1000 11  NT  d: 

SEQ 

SKIP 


9.^ 


#  File:  projh.occ 


#OPTION  "AGNVW" 

#INCLUDE  "hostio.inc" 

PROC  proj. harness  (CHAN  OF  SP  FromAda,  ToAda, 

CHAN  OF  ANY  Debug, 

[]INT  FreeMemory) 

#IMPORT  "projh2.tax'' 

[1]INT  dummy. ws: 
ws  IS  FreeMemory': 

[21INT  in. program,  out. program: 

SEQ 

-  Set  up  vector  of  pointers  to  channels. 
in.program[0]  :=  MOSTNEG  INT  —  not  used 
LOAD. INPUT. CHANNEL  (in.program[l],  ToAda) 
LOAD.OUTPUT.CHANNEL  (out.program[01.  Debug) 
LOAD.OUTPUT.CHANNEL  (out.programf  1],  FromAda) 

--  Invoke  the  Ada  program. 

--  Assumes  the  entry  point  name  has  been  changed  to  "proj. program", 
proj. program  (ws,  in. program,  out. program,  dummy. ws) 
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APPENDIX  F 


In  multiple  transputer  systems,  there  is  a  need  for  the  Occam  Harness  to  support  the 
Ada  program.  Each  Ada  program  run  on  individual  transputer  needs  its  own  mini-harness. 
This  appendix  provides  all  support  code  for  the  network  of  five  transputers.  For  general 
purpose  of  this  support  code,  assume  that  the  Ada  program  run  on  transputer  Tq  has  the 
main  procedure  named  PROJO  and  is  in  the  file  PRPJO.ADA,  the  Ada  program  runs  on 
transputer  T'j  has  the  main  procedure  named  PROJl  and  is  in  the  file  PROJl.ADA,  and 
so  on.  All  the  support  code  is  the  following; 

-  makefile 

-  family. inv 

-  proj?.inv  5  files 

-  mainh.occ 

-  merger.occ 

-  proj'i’h.occ  5  files 

-  proj?h2.occ  5  files 

-  main.pgm 
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#  File:  makefile 


#  "make  help"  tc  print  option  list 

# 

#  Complete  development  cycle; 

#  make  family  -  makes  Ada  family  and  library  directories 

#  make  -  compiles,  links,  configures  source 

#  make  run  --  run  bootable  code 

MODE  =  s 
PROC  =  8 

OPTS  =  /$(MODE)  /t$(PROC) 

#  make  the  executable  code 

main.btl:  m  ai  n  h  .  c  $  ( P  R  O  C )  $  ( M  OD  E)  proj  1  h  .  c  $  ( PR  OC)  $  (  M  O  DE ) 

proj2h.cS(PROC)S(MODE)  proj3h.cS(PROC)$(MODE)  proj4h.c$(PROC)S(MODE) 
main.pgm 

@  e^cho  EXPECT  1  WARNING...  PRAY  FOR  !!!..  SUCCESSFUL 
iconf  /s  main.pgm 
(a  f:\util\bell 

mainh  .c$(PROC)$(MODE):  projO.o  p  r  oj  Oh  .  t  $  ( P  R  O  C )  $  ( M  O  D  E ) 
merger.tS(PROC)$(MODE)  mainh.t$(PROC)$(MODE) 

ilink  mainh. t$(PROC)$(MODE)  projO.o  projOh.t$(PROC)$(MODE) 
merger.tS(PROC)S(MODE)  adartsS.lib  hostio.lib  occamSs.lib 

projO.o;  common. ada  projO.ada 
ada  invoke  projO.inv.ycs 

projOh.t$(PROC)$(MODE):  proj0h2.tax  projOh.occ 
Occam  $(OPTS)  projOh.occ 

proj0h2.tax:  proj0h2.occ 
Occam  /ta  /x  proj0h2.occ 

merger.t$(PROC)$(MODE):  merger.occ 
Occam  SfOPTS)  merger.occ 

mainh.tSfPROC)S(MODE):  mainh. occ 
Occam  $(OPTS)  mainh. occ 

projlh.c$(PROC)$(MODE):  projl.o  prnjlh.t$(PROC)$(MODE) 

ilink  projlh.t$(PROC)$(MODEj  projl.o  adartsS.lib  hostio.lib  occamSs.lib 
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proji.o:  common. ada  projl.ada 
ada  invoke  projl.inv,yes 

projlh.t$(PROC)$(MODE):  projlh2.tax  projlh.occ 
Occam  $(OPTS)  projlh.occ 
projlh2.tax:  projlh2.occ 
Occam  Aa  /x  projlh2.occ 

proj2h.c$(PROC)$(MODE):  proj2.o  proj2h.t$(PROC)$(MODE) 

ilink  proJ2h.t$(PROC)$(MODE)  proj2.o  adartsS.lib  hostio.lib  occamSs.lib 

proJ2.o:  common. ada  proj2.ada 
ada  invoke  proj2.inv,yes 

proj2h.tS(PROC)$(MODE);  proj2h2.tax  proj2h.occ 
Occam  $(OPTS)  proJ2h.occ 
proj2h2.tax:  proj2h2.occ 
Occam  Aa  /x  proj2h2.occ 

proj3h.c$(PROC)$(MODE):  proj3.o  proj3h.t$(PROC)$(MODE) 

ilink  proj3h.t$(PROC)$(MODE)  proJ3.o  adartsS.lib  hostio.lib  occamSs.lib 

proj3.o;  common. ada  proJ3.ada 
ada  invoke  proJ3.inv,yes 

P''oj3h.t$(PROC)S(MODE):  proJ3h2.tax  proj3h.occ 
Occam  $(OPTS)  proj3h.occ 
proJ3h2.tax:  proj3h2.occ 
Occam  Aa  /x  proj3h2.occ 

proj4h.cS(PROC)S(MODE);  proj4.o  proj4h.t$(PROC)$(MODE) 

ilink  proj4h.t$(PROC)$(MODE)  proi4.o  adartsS.lib  hostio.lib  occamSs.lib 

proj4.o:  common. ada  proj4.ada 
ada  invoke  proJ4.inv,yes 

proJ4h.tS(PROC)S(MODE):  proJ4h2.tax  proJ4h.occ 
Occam  S(OPTS)  projdh.occ 
proi4h2.tax:  proj4h2.occ 
Occam  Aa  /x  proj4h2.Gcc 

#  misc. 

run:  iserver  /sb  main.btl 

tamily:  ada  invoke  family. inv.yes 
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File:  projO.inv 

default. compile  library=test_lib 
compile  common. ada 
compile  projO.ada 

default. bind  library=test_lib,level=bind,waming=no 
bind  projO,object="proj0.o",entr>_point="proj0.program" 


File:  projl.inv 


default. compile  library=test_Ub 
compile  common. ada 
compile  projl.ada 

default. bind  library =test_lib,level=bind,w'aming=no 
bind  proj  1  .object="proj  I  .o",entr\'_point="proj  1  .program" 


File:  proj2.inv 


default. compile  library=test_lib 
compile  common. ada 
compile  proj2.ada 

default. bind  library=test_lib,level=bind.waming=no 
bind  proj2,object="proj2.o",entry_point="proj2. program” 


File:  proj3.inv 


default. compile  library=te.st_lib 
compile  common. ada 
compile  proj3.ada 

default. bind  library=te.st_lib,level=bind,waming=no 
bind  proj3,object="proj3.o", entry _point="proj3. program" 


File:  proj4.inv 


default. compile  library=test_lib 
compile  common. ada 
compile  proj4.ada 

default. bind  library=test_lib,level=bind,waming=no 
bind  proj4,object="proj4.o",entry__point="proj4. program" 
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-  File:  family. inv 


family. new  test_fam,overwrite=yes 
lib(family=test_fam).new  test_lib,overwrite=yes 


-  File:  mainh.occ 


#OPTION  "AGNVW" 

#1NCLUDE  "hostio.inc” 

PROC  main. harness  (CHAN  OF  SP  FromFiler,  ToFiler, 

CHAN  OF  INT  AdaChannel, 

(]INT  FreeMemory) 

#USE  "hostio.lib" 

#USE  "projOh.tSs" 

#USE  "merger. t8s" 

inCHAN  OF  ANY  Debug: 

12ICHAN  OF  SP  FromAda,  ToAda: 

CHAN  OF  BOOL  StopDebug,  StopMultiplexor: 

SEQ 

PAR 

-  A  multiplexor  to  combine  the  debug  and  normal  output. 

so. multiplexor  (FromFiler,  ToFiler,  FromAda,  ToAda,  StopMultiplexor) 

-  A  debug  channel  merger. 

debug. merger  (ToAdalOl,  FromAda[01,  Debug,  StopDebug) 

-  A  process  to  invoke  the  sieve  program. 
w'S  IS  FreeMemory: 

SEQ 

projO.harness  (FromAda[l],  ToAda[l),  DebugfO],  AdaChannel,  ws) 
StopDebug  !  FALSE 
StopMultiplexor  !  FALSE 

so.exit  (FromFiler,  ToFiler,  sps. success) 
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—  File:  merger.occ 


#OPTION  "AGNVW" 

#INCLUDE  "hostio.inc" 

PROC  debug. merger  (CHAN  OF  SP  FromFiler,  ToFiler, 
[]CHAN  OF  ANY  Debug, 

CHAN  OF  BOOL  Stop) 

#USE  "hostio.lib" 

—  A  debug  channel  merger  and  blocker. 

VAL  max. debug  IS  20: 

VAL  number.of.debug  IS  SIZE  Debug: 

INT  line. index: 

12561BYTE  line.buffer: 

BYTE  value,  r: 

BOOL  running,  reset,  s: 

[max.debuglBOOL  mask: 

VAL  BYTE  line.feed  IS  10  (BYTE): 

SEQ 

SEQ  i  =  0  FOR  number.of.debug 
mask!  i  I  :=  TRUE 
running  :=  TRUE 
reset  :=  FALSE 
line. index  :=  0 
WHILE  running 
PRI  ALT 

ALT  i  =  0  FOR  number.of.debug 
mask[i]  &  Debug[i1  ?  value 
SEQ 
IF 

value  =  line.feed 
SEQ 

-  Send  the  complete  line, 
so. puts  (FromFiler,  ToFiler,  spid.stdout, 
[line.buffer  FROM  0  FOR  line. index],  r) 
line. index  :=  0 
mask  [i]  :=  FALSE 
reset  :=  TRUE 
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TRUE 

SEQ 

-  Add  character  to  line, 
line. buffer[line. index]  :=  value 
line. index  :=  line. index  +  1 
reset  &  SKIP 


SEQ 

reset  :=  FALSE 

SEQ  i  =  0  FOR  number.of.debug 
mask[i]  :=  TRUE 
Stop  ?  s 

running  :=  FALSE 
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-  File:  projOh.occ 


#OPTION  "AGNVW 
#INCLUDE  "hostio.inc" 

PROC  projO.hamess  (CHAN  OF  SP  FromAda,  ToAda, 
CHAN  OF  ANY  Debug, 

CHAN  OF  INT  AdaChannel, 

[]INT  FreeMemory) 


#lMPORT  "proj0h2.tax" 

[HINT  dummy. ws: 
wsl  IS  FreeMemory: 

[31INT  in, program: 

[21INT  out. program: 

SEQ 

-  Set  up  vector  of  pointers  to  channels. 
in.program[01  :=  MOSTNEG  INT  -  not  used 

LOAD.INPUT.CHANNEL  (in. program!  1  ],  ToAda) 
LOAD.INPUT.CHANNEL  (in.program(2],  AdaChannel) 

LOAD. OUTPUT. CHANNEL  (out.programfO],  Debug) 

LOAD. OUTPUT. CHANNEL  (out.program|  1],  FromAda) 

--  Invoke  the  Ada  program. 

--  Assumes  the  entrs'  point  name  has  been  changed  to  "projO. program". 
projO. program  (wsl,  in. program,  out. program,  dummy. ws) 


--  File:  proj0h2.occ 


#0PT10N  "AEV" 

PROC  projO. program  ([]INT  wsl,  in,  out,  ws2) 
[1000] INT  d: 

SEQ 

SKIP 
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—  File:  projlh.occ 


#OPTION  "AGNVW" 

#INCLUDE  "hostio.inc" 

PROC  projl. harness  (CHAN  OF  INT  AdaChannel, 

CHAN  OF  INT  AdaChan, 

[]INT  FreeMemory) 

#IMPORT  "projIh2.tax" 

[1]INT  dummy. ws: 
wsl  IS  FreeMemory: 
ws2  IS  FreeMemory: 

1 3] INT  in. program: 

[3]INT  out. program: 

SEQ 

--  Set  up  vector  of  pointers  to  channels. 
in.program[0]  :=  MOSTNEG  INT  —  not  used 

LOAD.INPUT.CHANNEL  (in. program! 2],  AdaChan) 
LOAD.OUTPUT.CHANNEL  (out.program[21,  AdaChannel) 

--  Invoke  the  Ada  program. 

--  Assumes  the  entiy-  point  name  has  been  changed  to  "projl. program", 
proj  1  .program  (\ns1,  in. program,  out. program,  ws2) 


--  File:  proJlh2.occ 


#OPTION  "AEV" 

PROC  projl. program  (HINT  wsl,  in,  out,  ws2) 
fl(X)01INT  d: 

SEQ 

SKIP 
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—  File:  proj2h.occ 


#OPTION  "AGNVW " 

#INCLUDE  "hostio.inc" 

PROC  proj2.hamess  (CHAN  OF  INT  AdaChan, 

CHAN  OF  INT  Achan, 

[]INT  FreeMemory) 

#IMPORT  "proj2h2.tax'' 

[IJINT  dummy. ws: 
wsl  IS  FreeMemory; 
ws2  IS  FreeMemoiy: 

[3]INT  in.program: 

[3] INT  out. program: 

SEQ 

--  Set  up  vector  of  pointers  to  channels. 
in.program[0|  :=  MOSTNEG  INT  --  not  used 

LOAD.INPUT.CHANNEL  (in. program! 2],  Achan) 
LOAD.OUTPUT.CHANNEL  (out.program(21,  AdaChan) 

--  Invoke  the  Ada  program. 

”  Assumes  the  entry  point  name  has  been  changed  to  ''proj2. program”. 
proj2. program  (wsl,  in.program,  out. program,  ws2) 


--  File:  proj2h2.occ 


#OPTION  "AEV” 

PROC  proj2. program  (HINT  wsl,  in,  out,  ws2) 
[1 0001  INT  d; 

SEQ 

SKIP 
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—  File:  proj3h.occ 


#0PT10N  ’  AGNVW" 

#INCLUDE  "hostio.inc" 

PROC  proj3.hamess  (CHAN  OF  INT  Achan, 

CHAN  OF  INT  Chan, 

[]INT  FreeMemory) 

#IMPORT  "proj3h2.tax" 

[  1  ]INT  dummy. ws: 
wsl  IS  FreeMemory: 
ws2  IS  FreeMemory: 

[3IINT  in. program: 

[3]INT  out. program: 

SEQ 

-  Set  up  vector  of  pointers  to  channels. 
in.programlO]  :=  MOSTNEG  INT  —  not  used 

LOAD.INPUT.CHANNEL  (in.program[2I,  Chan) 
LOAD.OUTPUT.CHANNEL  (out.program[2],  Achan) 

--  Invoke  the  Ada  program. 

-  Assumes  the  entry'  point  name  has  been  changed  to  "proj 3. program". 
proj3. program  (wsl,  in. program,  out. program,  ws2) 


--  File:  proj3h2.occ 


#OPTION  "AEV" 

PROC  proj3. program  (HINT  wsl,  in,  out,  ws2) 
[KKIOIINT  d: 

SEQ 

SKIP 
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--  File:  proj4h.occ 


#OPTION  "AGNVW  ” 
#INCLUDE  "hostio.inc” 


PROC  proj4.hamess  (CHAN  OF  INT  Chan, 
[lINT  FreeMemor}') 

#IMPORT  '’proj4h2.tax" 


[IjINT  dummy. ws: 
wsl  IS  FreeMemory; 

[2]INT  in. program; 

[3IINT  out. program: 

SEQ 

--  Set  up  vector  of  pointers  to  channels. 
in.program[0]  ;=  MOSTNEG  INT  —  not  used 
in. program!  1  ]  :=  MOSTNEG  INT  —  standard 
out.program[0]  ;=  MOSTNEG  INT  —  standard 
out. program!  1 1  :=  MOSTNEG  INT  —  standard 


i/o  not  used 
i/o  not  used 
i/o  not  used 


LOAD.OUTPUT.CHANNEL  (out.program[2],  Chan) 

--  Invoke  the  Ada  program. 

--  Assumes  the  entry  point  name  has  been  changed  to  ’'proj3. program". 
proj4. program  (wsl,  in. program,  out. program,  dummy. ws) 


--  File:  proj4h2.occ 


#OPTION  "AEV" 

PROC  proj4. program  (!1INT  wsl,  in,  out,  ws2) 
!  1000] INT  d: 

SEQ 

SKIP 
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#  File:  main.pgm 


#INCLUDE  "hostio.inc" 
#INCLUDE  "linkaddr.inc" 

#USE  "mainh.cSs” 

#USE  "projlh.cSs" 

#USE  ’’proj2h.c8s" 

#USE  ”proj3h.c8s” 

#USE  "proj4h.c8s" 


CHAN  OF  INT  AdaChannel; 

CHAN  OF  INT  AdaChan: 

CHAN  OF  INT  Achan; 

CHAN  OF  INT  Chan: 

CHAN  OF  SP  FromFiler,  ToFiler: 

PLACED  PAR 

PROCESSOR  0  T8 
PLACE  FromFiler  AT  linkO.in: 

PLACE  ToFiler  AT  linkO.out: 

PLACE  AdaChannel  AT  link2.in: 

[1000001  INT  wsl: 

main. harness  (FromFiler,  ToFiler,  AdaChannel,  wsl) 

PROCESSOR  1  T8 

PLACE  AdaChannel  AT  linkO.out: 

PLACE  AdaChan  AT  link2.in: 

[100(X)0]  INT  ws2: 

projl. harness  (AdaChannel,  AdaChan,  ws2) 

PROCESSOR  2  T8 

PLACE  AdaChan  AT  link.^.out: 

PLACE  Achan  AT  link2.in: 

[KXXXX)!  INT  ws3: 

proj2. harness  (AdaChan,  Achan.  ws3) 
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PROCESSOR  3  T8 


PLACE  Achan  AT  link3.out: 
PLACE  Chan  AT  link.2.in: 

llOOOOOl  INT  ws4; 

proj3. harness  (Achan,  Chan,  ws4) 

PROCESSOR  4  T8 

PLACE  Chan  AT  link3.out: 


[lOOOOO]  INT  ws5: 
proj4,harne<;';  (Chan,  ws5) 


APPENDIX  G 


This  appendix  provides  the  Ada  code  for  a  five  transputers  network.  Each  file  is  the 
Ada  program  that  runs  on  transputer  T„.  T,,  Tj,  T3,  T4,  and  T5  individually.  In  this 
appendix  also  provides  the  package  COMMON  in  file  COMMON. ADA  which  is  the 
declaration  of  common  data  types  used  for  channel  communication. 
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--  File;  common. ada 


with  CHANNELS; 
package  COMMON  is 

—  Declarations  of  common  data  types,  especially  those  used  for  channel 

—  communication. 

type  FLO_6  is  digits  6 

range  -(2.0  -  2.0**(-23))*2.0**127  ..  (2.0  -  2.0**(-23))*2.0**127; 
type  VECTOR  is  array  (0..2)  of  FLO_6; 

—  Instantiations  of  the  generic  channel  i/o  package. 

package  VECTOR.IO  is  new  CHANNELS.CHANNEL_IO  (VECTOR); 
end  COMMON; 
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-  File:  projO.ada 


with  TEXT_IO,  COMMON,  CHANNELS; 
use  COMMON; 

procedure  PRO  JO  is 


package  FLO_IO  is  new  TEXTJO.FLOAT_IO(FLO_6); 
use  FLO_IO: 

RESULT  :  VECTOR; 

RES  :  VECTOR; 

TOTAL  :  VECTOR; 

TOL  :  VECTOR; 

SUM  ;  VECTOR; 

D  :  CHANNELS. CHANNEL_REF  :=  CHANNELS.IN_PARAMETERS  (2); 

--  The  channel  used  for  communication  with  the  program  producing  the  stream. 
—  Input  channels  0  and  1  are  reserved  for  use  by  the  run-time  system. 

begin 

for  J  in  1..5  loop 

SUM  ;=  (500.00,500.00.500.00); 

TEXT_IO.PUT  ("DATA  FROM  TRANSPUTER  #  0  "  ); 

FLO_IO.PUT  (SUM(O),  FORE  =>  4,  AFT  =>  2,  EXP  =>  0); 

FLOJO.PUT  (SUM(l),  FORE  =>  4,  AFT  =>  2.  EXP  =>  0); 

FLO_IO.PUT  (SUM(2).  FORE  =>  4,  AFT  =>  2,  EXP  =>  0); 

TEXT_IO.NEW_LINE; 
end  loop; 

loop 

VECTOR_IO.READ  (D,  TOTAL); 
exit  when  TOTAL(O)  <  0.0; 

TEXT_IO.PUT  ("DATA  FROM  TRANSPUTER  #  1  "  ); 

FLO_IO.PUT  (TOTAL(O),  FORE  =>  4,  AFT  =>  2,  EXP  =>0); 

FLO_10.PUT  (TOTAL(l),  FORE  =>  4,  AFT  =>  2,  EXP  =>0); 

FLO_IO.PUT  (TOTAL(2),  FORE  =>  4,  AFT  =>  2,  EXP  =>0); 
TEXT_IO.NEW_LINE; 
end  loop; 
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loop 

VECTORJO.READ  (D,  TOL); 
exit  when  TOL(O)  <  0.0; 

TEXTJO.PUT  ("DATA  FROM  TRANSPUTER  #  2  "  ); 
FLO_IO.PUT  (TOL(O),  FORE  =>  4,  AFT  =>  2,  EXP  =>0) 
FLOJO.PUT  (TOL(l),  FORE  =>  4,  AFT  =>  2,  EXP  =>0) 
FLO_10.PUT  (TOL(2),  FORE  =>  4.  AFT  =>  2,  EXP  =>0) 
TEXT_IO.NEW_LINE; 
end  loop; 


loop 

VECTORJO.READ  (D,  RES); 
exit  when  RES(O)  <  0.0; 

TEXTJO.PUT  ("DATA  FROM  TRANSPUTER  #  3  "  ); 
FLOJO.PUT  (RES(O),  FORE  =>  4,  AFT  =>  2,  EXP  =>  0); 
FLOJO.PUT  (RES(l),  FORE  =>  4,  AFT  =>  2,  EXP  =>  0); 
FLOJO.PUT  (RES(2),  FORE  =>  4,  AFT  =>  2,  EXP  =>  0); 
TEXTJO.NEW_LINE; 
end  loop; 

loop 

VECTORJO.READ  (D,  RESULT); 
exit  when  RESULT(O)  <  0.0; 

TEXT_IO.PUT  ("DATA  FROM  TRANSPUTER  #  4  "  ); 
FLO.IO.PUT  (RESULT(0),  FORE  =>  4,  AFT  =>  2,  EXP  =>  0) 
FLOJO.PUT  (RESULT(l),  FORE  =>  4,  AFT  =>  2,  EXP  =>  0) 
FLOJO.PUT  (RESULT(2),  FORE  =>  4,  AFT  =>  2,  EXP  =>  0) 
TEXT_10.NEW_LINE; 
end  loop; 


end  PROJO; 


-  File:  projl.ada 


with  TEXT_IO,  COMMON,  CHANNELS; 
use  COMMON; 


procedure  PROJl  is 

RESULT  :  \TCTOR; 

RES  :  VECTOR; 

TOTAL  :  VECTOR; 

TOL  :  VECTOR; 

C  :  CHANNELS.CHANNEL_REF  :=  CHANNELS. IN_PARAMETERS  (2); 

D  :  CHANNELS.CHANNEL_REF  :=  CHANNELS.OUT_PARAMETERS  (2); 
—  The  channel  used  for  communication  with  the  program  producing  the  stream. 


begin 

for  J  in  1..5  loop 

TOTAL  :=  (400.00,400.00,400.00); 
VECTOR_IO.WRITE  (D,  TOTAL); 
end  loop; 

TOTAL(O)  :=  -1.00; 

VECTOR.IO. WRITE  (D,  (TOTAL(0),0.00,0.00)); 
loop 

VECTOR_IO.READ  (C,  TOL); 
VECTOR_IO.WRITE  (D,  TOL); 
exit  when  TOL(O)  <  0.0; 
end  loop; 

loop 

VECTORJO.READ  (C,  RES); 
VECTOR_IO.WRlTE  (D,  RES); 
exit  when  RES(O)  <  0.0; 
end  loop; 

loop 

VECTOR_IO.READ  (C,  RESULT); 
VECTOR_IO.WRITE  (D,  RESULT); 
exit  when  RESULT(O)  <  0.0; 
end  loop; 
end  PROJl; 


113 


—  File:  proj2.ada 


with  TEXT_IO; 
with  COMMON; 
with  CHANNELS; 

procedure  PROJ2  is 

use  COMMON; 

RESULT  :  VECTOR; 

RES  :  VECTOR; 

TOL  :  VECTOR; 

B  :  CHANNELS. CHANNEL_REF  :=  CHANNELS.IN_PARAMETERS  (2); 

C  :  CHANNELS.CHANNEL_REF  :=  CHANNELS .OUT_PARAMETERS  (2); 
--  The  channel  for  communication  with  the  other  Ada  program. 

—  Output  channels  0  and  1  are  reserved  for  use  by  the  run-time  system. 

begin 

for  I  in  1  ..  5  loop 

TOL  :=  (300.00,300.00,300.00); 

VECTOR_IO.WRITE  (C,  TOL); 
end  loop; 

TOL(O)  :=  -1.00; 

VECTORJO.WRITE  (C,  (TOL(0),0.0,0.0)); 


loop 

VECTOR_IO.READ  (B,  RESULT); 
VECTORJO.WRITE  (C,  RESULT); 
exit  when  RESULT(O)  <  0.0; 
end  loop; 

loop 

VECTOR JO.READ  (B,  RES); 
VECTORJO.WRITE  (C,  RES); 
exit  when  RES(O)  <  0.0; 
end  loop; 

end  PROJ2; 
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-  File:  proj3.ada 


with  TEXT_IO; 
with  COMMON; 
with  CHANNELS; 

procedure  PROJ3  is 

use  COMMON; 

RESULT  :  VECTOR; 

RES  :  VECTOR; 

A  :  CHANNTLS.CHANNEL_REF  :=  CHANNELS.IN_PARAMETERS  (2); 

B  :  CHANNELS. CHANNEL_REF  :=  CHANNELS.OUT_PARAMETERS  (2); 
--  The  channel  for  communication  w'ith  the  other  Ada  program. 

--  Output  channels  0  and  1  are  reserved  for  use  by  the  run-time  system. 

begin 


for  I  in  1  ..  5  loop 

RES  :=  (200.00,200.00,200.00); 
VECTORJO.WRITE  (B,  RES); 
end  loop; 

RES(O)  :=  -1.00; 

VECTOR_IO.WRITE  tB,  (RES(0).0.0,0.0)); 
loop 

VECTOR_IO.READ  (A,  RESULT); 
VECTOR_IO.WRITE  (B,  RESULT); 
exit  when  RESULT(())  <  0,0; 
end  kxip; 

end  PROJ3; 
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-  File:  proj4.ada 


with  TEXT_IO; 
with  COMMON; 
with  CHANNELS; 

procedure  PROJ4  is 

use  COMMON; 

RESULT  :  VECTOR; 

A  :  CHANNELS.CHANNEL_REF  :=  CHANNELS.OUT_PARAMETERS  (2); 
--  The  channel  for  communication  with  the  other  Ada  program. 

--  Output  channels  0  and  1  are  reserved  for  use  by  the  run-time  system. 

begin 

for  I  in  1  ..  5  loop 

RESULT  :=  (KXl.OO,  100.00, 100.00); 

VECTOR_10.WRITE  (A,  RESULT); 
end  l(K)p; 

RESULT(O)  ;=  -1.00; 

VECTOR_IO.WRITE  (A,  (RESULT(0),0.0.0.0)); 
end  PROJ4; 
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Booting  root  transputer.. .ok 
DATA  FROM  TRANSPUTER  #  0 
DATA  FROM  TRANSPUTER  #  0 
DATA  FROM  TRANSPUTER  #  0 
DATA  FROM  TRANSPUTER  #  0 
DATA  FROM  TRANSPUTER  #  0 
DATA  FROM  TRANSPUTER  #  1 
DATA  FROM  TRANSPUTER  #  1 
DATA  FROM  TRANSPUTER  #  1 
DATA  FROM  TRANSPUTER  #  1 
DATA  FROM  TRANSPUTER  #  1 
DATA  FROM  TRANSPUTER  #  2 
DATA  FROM  TRANSPUTER  #  2 
DATA  FROM  TRANSPUTER  #  2 
DATA  FROM  TRANSPUTER  #  2 
DATA  FROM  TRANSPUTER  #  2 
DATA  FROM  TRANSPUTER  #  3 
DATA  FROM  TRANSPUTER  #  3 
DATA  FROM  TRANSPUTER  #  3 
DATA  FROM  TRANSPUTER  #  3 
DATA  FROM  TRANSPUTER  #  3 
DATA  FROM  TRANSPUTER  #  4 
DATA  FROM  TRANSPUTER  #  4 
DATA  FROM  TRANSPUTER  #  4 
DATA  FROM  TRANSPUTER  #  4 
DATA  FROM  TRANSPUTER  #  4 


500.00  500.00  500.00 
500.00  5(X).00  500.(X) 
500.00  500.00  500.00 
500.00  500.00  500.(X) 
500.00  500.00  500.00 
400.00  400.00  400.00 
400.00  400.00  400.00 
400.00  400.00  400.00 
400.00  400.00  400.00 
400.00  400.00  400.00 
300.00  300.00  300.00 
300.00  300.00  300.(X) 
300.00  300.00  300.00 
300.00  300.00  300.00 
300.00  300.00  300.00 
200.00  200.00  200.00 
200.00  200.00  200.00 
200.00  2(X).00  200.00 
200.00  200.00  200.00 
200.(X)  200.00  200.00 
100.00  100.00  100.00 
100.00  100.00  100.00 
100.00  100.00  100.00 
100.00  100.00  100.00 
100.00  100.00  100.00 


MAKE  Program  Maintenance  Utility,  Logical  Systems  Version  89.1 
iserv'er  /sb  main.btl 
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APPENDIX  H 


This  appendix  provides  the  code  of  Small  Tactical  System  in  a  three  transputers 
network.  Since  this  is  also  the  multiple  transputer  network,  the  suppon  code  in 
APPENDIX  F  can  be  used.  There  is  only  a  few  change  in  file  "makefile”  and  "main.pgm" 
which  is  shown  in  this  appendix. 
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-  File;  common. ada 


with  CHANNELS; 
package  COMMON  is 

-  Declarations  of  common  data  types,  especially  those  used  for  channel 
--  communication. 

type  FLO_6  is  digits  6 

range  -(2.0  -  2.()**(-23))*2.0**127  ..  (2.0  -  2.0**(-23))*2.0**127; 

type  COMPONENT  is  (X,Y,Z); 

type  VECTOR  is  array  (COMPONENT)  of  FLO_6; 

type  ARY_7  is  array  (0..6)  of  VECfOR; 

type  VEC_3  is  array  (0..2)  of  FLO_6; 

-  Instantiations  of  the  generic  channel  i/o  package. 

package  VECTOR_IO  is  new  CHANNELS.CHANNEL.IO  (VEC_3); 
package  ARRAY_IO  is  new  CHANNELS.CHANNEL_IO  (ARY_7); 

end  CO.M.MON; 
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—  File:  projO.ada 


with  TEXT_IO,  COMMON,  CHANNELS; 
procedure  PROJO  is 
use  COMMON; 

package  FLO_IO  is  new  TEXTJO.FLOAT_IO(FLO_6); 
use  FLO_IO; 

RESULT  :  VEC_3; 

TOTAL  :  VEC_3; 

SUM  :  VEC_3; 

D  :  CHANNELS.CHANNEL_REF  :=  CHANNELS. IN_PAR  A  METERS  (2); 

--  The  channel  used  for  communication  with  the  program  producing  the  stream. 
-  Input  channels  0  and  1  are  reserved  for  use  by  the  run-time  system. 


begin 


for  J  in  1..5  loop 

SUM  :=  f'OO.OO, 500.00, 500.00); 

TEXT  iO.PUT  ("DATA  FROM  TRANSPUTER  #  0  "  ); 
FLO.IO.PUT  (SUM(O),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
FLO_IO.PUT  (SUM(l),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
fLO_IO.PUT  (SUM(2),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
TEXT_IO.NEW_LINE; 
end  loop; 

loop 

VECTOR_IO.READ  (D,  TOTAL); 
e,\it  when  TOTAL(O)  <  0.0; 

TEXTJO.PUT  ("DATA  X  FROM  TRANSPUTER  #  1  "  ); 
FL0_10.PUT  (TOTAL(O),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
FLO_IO.PUT  (TOTAL(l),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
FLOJO.PUT  (TOTAL(2),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
TEXT_IO.NE\V_LINE; 

VECTOR_IO.READ  (D,  TOTAL); 

TEXTJO.PUT  ("DATA  Y  FROM  TRANSPUTER  #  1  "  ); 
FLO_ IO.PUT  (TOTAL(O).  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
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FLOJO.PUT  (TOTAL(l),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
FLOJO.PUT  (TOTAL(2),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
TEXT_IO.NEW_LINE; 

VECTOR_IO.READ  (D,  TOTAL); 

TEXTJO.PUT  ("DATA  Z  FROM  TRANSPUTER  #  1  "  ); 
FLO_IO.PUT  (TOTAL(O),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
FLO_IO.PUT  (TOTAL(l),  PORE  =>  6.  AFT  =>  4,  EXP  =>  0); 
FLO_IO.PUT  (TOTAL(2),  FORE  =>  6,  AFT  =>  4,  EXP  =>  0); 
TEXT_IO,NEW_LINE; 

end  loop; 

end  PROJO; 
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-  File:  projl.ada 


with  TEXTJO,  COMMON,  CHANNELS; 
use  TEXT_IO,  COMMON; 

procedure  PROJl  is 

B  :  ARY_7; 

TOTAL  ;  VEC_3; 

C  :  CHANNELS.CHANNEL_REF  :=  CHANNELS.IN_PARAMETERS  (2); 

D  :  CHANNELS.CHANNEL_REF  :=  CHANNELS. OUT_PARA METERS  (2); 
--  The  channel  used  for  communication  with  the  program  producing  the  stream. 
--  Input  channels  0  and  1  are  re.served  for  use  by  the  run-time  system. 

-  type  identification 

type  COMPONENTS  is  (X0,XLX2,X3,X4,X5,X6); 
type  VECTORS  is  array  (COMPONENTS)  of  FLO_6; 
type  POSITIONS  is  array  (0..3)  of  FLO_6; 
type  VEC  is  array  (()..2)  of  FLO_6; 

-  orthogonal  constant 

CONSTO  ;  VECTORS  :=  (1.0, 1.0, 1.0, 1. 0,1. 0,1. 0,1.0); 

CONSTl  :  VECTORS  ;=  (1.0,0.666,0.333,0.0,-0.333,-0.666,-1.0); 

CONST2  :  VECTORS  :=  (1.0,0.0,-0.6,-0.8,-0.6,0.0,1.0); 

CONST3  :  VECTORS  :=  (1. 0,-1. 0,-1. 0,0.0, 1.0, 1.0,- 1.0); 

T.U,V  :  VECTORS  :=  (0.0,0.0,0.0,0.0,0.0,0.0,0.0); 

POS_X,POS_Y,POS_Z  :  POSITIONS  (0.0,0.0,0.0,0.0); 

COEF  :  VEC; 

function  VECTOR_SUM  (X  :  VECTORS)  return  FLO_6  is 
SUM  :  FLO_6  :=  0.0; 
begin 

for  I  in  X’RANGE  loop 
SUM  :=  SUM  +  X(I); 
end  loop; 
return  SUM; 
end  VECTOR_SUM; 
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function  VECTOR_SUM_SQUARE  (X  :  VECTORS)  return  FLO_6  is 
SUM_SQUARE  :  FLO_6  0.0; 
begin 

for  I  in  X’RANGE  loop 

SUM_SQUARE  :=  SUM.SQUARE  +  (X(I)**2); 
end  loop; 

return  SUM^SQUARE; 
end  VECTOR_SUM_SQUARE; 

function  ORTHOGONAL  (POSJN  ;  VECTORS)  return  POSITIONS  is 
TEMPO, TEMP  1,TEMP2,TEMP3  ;  VECTORS; 
POS_OUTO,POS_OUTLPOS_OUT2,POS_OUT3  ;  FLO_6; 

ORTHO  :  POSITIONS; 
begin 

for  I  in  COMPONENTS  loop 

TEMPO(I)  ;=  POS_IN(I)  *  CONSTO(l); 

TEMPl(I)  :=  POS_IN{I)  *  CONSTl(I); 

TEMP2(I)  :=  POS_IN(I)  *  CONST2(I); 

TEMP3(I)  :=  POSJN(I)  *  CONST3(l); 
end  loop; 

POS_OUTO  :=  VECTOR_SUM(TEMPO)A'ECTOR_SUM_SQUARE(CONSTO); 
POS_OUTl  ;=  VECTOR_SLM(TEMPI)A'ECTOR_SUM_SQUARE(CONSTl); 
POS_OUT2  :=  VECTOR_SUM(TEMP2)/VECTOR_SUM_SQUARE(CONST2); 
POS_OUT3  :=  VECTOR_SL’M(TEMP3)A'ECTOR_SUM_SQUARE(CONST3); 
ORTHO  ;=  (POS_OUTO,POS_OUTLPOS_OUT2,POS_OUT3); 
return  ORTHO; 
end  ORTHOGONAL; 

function  COEFF_CAL  (A  ;  in  POSITIONS)  return  VEC  is 
a0.aLa2  ;  FLO_6;  V  :  VEC; 
begin 

',i0  :=  A(0)+A(l)+A(2)+A(3); 

al  (-A(l)*i0.3333))+(A(2)*(-L2))+(-A(3)*(0.6667)); 
a2  (A(2)*(0.200()))+(A(3)*(I.500)k 
V  ;=  (a0.aLa2); 
return  V; 

end  COEFF_CAL; 


begin 

loop 

ARRAYJO.READ  (C,  B); 
exit  when  B(0)(X)  <  0.0; 


T!X0) 

=  B!0)!X) 

U!X0) 

=  B!0)!Y) 

V!X0) 

=  B!0)!Z) 

T!X1) 

=  B!1)!X) 

J!X1) 

=  B!1)!Y) 

V!X1) 

=  B!1)!Z) 

T!X2) 

=  B!2)!X) 

U!X2) 

=  B!2)!Y) 

V!X2) 

=  B!2)!Z) 

T!X3) 

=  B!3)!X) 

U!X3) 

=  B!3)!Y) 

V!X3) 

=  B!3)!Z) 

T!X4) 

=  B!4)!X) 

U!X4) 

=  B!4)!Y) 

V!X4) 

=  B!4)!Z) 

T!X5) 

=  B!5)!X) 

U!X.‘i) 

=  B!5)!Y) 

V!X5) 

=  B!5)!Z) 

T!X6) 

=  B!6)!X) 

U!X6) 

=  B!6)!Y) 

V!X6) 

=  B!6)!Z) 

POS_X  ;=  ORTHOGONAL(T); 

COEF  ;=  COEFF_CAL(POS_X); 

TOTAL(O)  :=  FLO_6(COEF(0)); 

TOTAL(l)  ;=  FLO_6(COEF(l)); 

TOTAL(2)  :=  FLO_6(COEF(2)); 
VECTORJO.WRITE  (D,  TOTAL); 

POS_Y  :=  ORTHOGONAL(U); 

COEF  :=  COEFF_CAL(POS_Y); 

TOTAL(O)  :=  FLO_6(COEF(0)); 

TOTAL(l)  :=  FLO_6(COEF(l)); 

TOTAL(2)  :=  FLO_6(COEF(2)); 
VECTORJO.WRITE  (D,  TOTAL); 

POS_Z  :=  ORTHOGONAL! V;; 

COEF  :=  COEFF_CAL(POS_Z); 

TOTALfO)  ;=  FLO_6(COEF(0)); 

TOTAL!  1)  :=  FLO„6!COEF!  1 )); 

TOTAL!2)  :=  FLO_6!COEF!2)); 
VECTOR_IO. WRITE  >3.  TOTAL); 

end  loop; 

TOTAL!0)  :=  -1.0; 

VECTOR_IO.WRlTE  !D,  !TOTAL!0),  0.0,  0.0)); 
end  PROJl; 
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--  Pile;  proj2.ada 


with  TEXTJO,  CALENDAR,  GENERIC_ELEMENTARY_FUNCnONS; 

with  COMMON,  CHANNELS; 

use  TEXT^IO,  CALENDAR,  COMMON; 


procedure  PROJ2  is 

package  MATH_FUNCT  is  new  GENERlC_ELEMENTARY_FUNCTIONS(FLO_6); 
use  MATH_FUNCT; 

C  :  CHANNELS.CHANNEL_REF  :=  CHANNELS.OUT_PARAMErERS  (2); 

--  The  channel  for  communication  with  the  other  Ada  program. 

--  Output  channels  0  and  1  are  reserved  for  use  by  the  run-time  system. 

-  Type  identifications 

type  VELOCITIES  is  array  (0..4)  of  VECTOR; 

DELTA_T[.ME  ;  constant  FLO_6  :=  0.25;  --  delta  time  t  =  1/4  seconds 
NO.TARGET  :  BOOLEAN  :=  FALSE; 

CURRENT  :  constant  INTEGER  :=  4; 

LINT_SEC  :  INTEGER; 

INTERVAL  ;  DAY_DURATION  :=  1.0; 

D1SP_TIME  ;  DAY_DURATION  :=  0.0; 

POSITION  :  VECTOR  :=  (27000.0,22000.0,5000.0); 

P,P0,PLP2,P3,P4,P5,P6  ;  VECTOR; 

INT_VEL  :  VECTOR  :=  (230.0,180.0,25.0); 

VELOCITY  :  VELOCITIES; 

B  ;  ARY_7; 

function  "+  "(LEFT,  RIGHT  :  in  VECTOR)  return  VECTTOR  is 


-  This  function  is  written  to  handle  VECTOR  addition 


TEMP  ;  VE(7rOR; 
begin 

TEMP(X)  :=  LEFT(X)  +  RIGHT(X); 
TEMP(Y)  :=  LEFT(Y)  -i-  RIGHT(Y); 
TEMP(Z)  LEFT(Z)  +  RIGHT(Z); 
return  TEMP; 
end 


125 


function  "-"(LEFT,  RIGHT  ;  in  VECTOR)  return  VECTOR  is 


--  This  function  is  written  to  handle  VECTOR  subtraction 


TEMP  :  VECTOR; 
begin 

TEMP(X)  :=  LEFT(X)  -  RIGHT(X); 

TEMP(Y)  :=  LEFT(Y)  -  RIGHT(Y); 

TEMP(Z)  ;=  LEFT(Z)  -  RIGHT(Z); 
return  TEMP; 
end 

function  SIMPSON(XPOS;  in  VECTOR;  VEL:  in  VELOCITIES)  return  VECTOR  is 


—  This  function  performs  numeric  integration  using  SIMPSONS  rule  and 
--  return  a  position  vector  giving  a  set  of  sample  VELOCITIES  and  the 

—  DELTA_TIME  between  those  velocities. 


T  :  VECTOR; 

I  :  COMPONENT; 

J  :  INTEGER; 
begin 

for  I  in  COMPONENT  loop 

T(I)  :=  (VEL(  VELOCITIES ’FIRST)  (I)  -h  VEL(VELOCITIES’LAST)  (I)); 
for  J  in  VELOCITIES’FIRST+L.VELOCrriES’LAST-l  loop 
if  (J  MOD  2)  =  1  then 

T(I)  :=  T(I)  +  4.0*VEL(J)  (I); 
else 

T(I)  :=  T(I)  -t-  2.0*VEL(J)  (I); 
end  if; 
end  loop; 

T(I)  ;=  DELTA_T1ME  *  T(I)  /  3.0; 
end  loop; 
return  T; 
end  SIMPSON; 

package  ATOD  is 


--  This  package  is  used  to  maintain  the  velocity  values  for  the  previous  second  at  1/4 
--  second  interv'als.  It  has  one  function  which  returns  an  array  of  five  vectors. 

--  The  task  is  written  to  handle  concurrent  processing  of  ACCELEROMETER. 


procedure  INITIALlZE_VELOCITY(FIRST_VEI  :  in  VECTOR); 
procedure  GET_VELOCITIES(NEW_VEL  :  out  VELOCITIES); 

task  ACCELEROMETER  is 
entr>'  START; 
end  ACCELEROMETER; 

end  ATOD; 

package  body  ATOD  is 

VEL  :  VELOCITIES  :=  (others  =>  (others  =>  0.0)); 

procedure  INmALIZE_VELOCITY(FIRST_VEL  ;  in  VEtCTOR)  is 
I  :  INTEGER; 
begin 

for  I  in  VELOCITIES 'RANGE  loop 
VEL(I)  :=  FIRST_VEL; 
end  loop; 

end  INITIALIZE_VELOCITY; 

procedure  GET_VELOCITIES(NEW_VEL  ;  out  VELOCITIES)  is 
begin 

NEW_VEL  :=  VEL; 
end  GET_VELOCITIES; 

task  body  ACCELEROMETER  is 
use  CALENDAR; 

INTERVAL  ;  constant  DURATION  ;=  0.25; 

DISP.TIME  ;  DURATION  ;=  0.0; 

LINT_SEC  :  INTEGER  :=  0; 

begin 

accept  START  do 
null; 

end  START; 

LINT_SEC  :=  INTEGER(SECONDS(CLOCK)); 

DISP_TIME  ;=  DURAT10N(LINT_SEC); 
while  DISP_TIME  <  SECONDS(CLOCK)  loop 
DISP_TIME  :=  DISP_TIME  +  INTERVAL; 
end  loop; 
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loop 

delay  DISP_TIME  -  SECONDS(CLOCK); 
for  I  in  VELOCITIES ’FIRST..  VELOCITIES ’LAST- 1  loop 
VEL(I)  :=  VEL(I-t-l); 
end  loop; 

VEL(  VELOCITIES ’LAST)  :=  VEL( VELOCITIES ’LAST)  -h 
(0.012,0.0098,0.00275); 
exit  when  VEL(4)(X)  >  700.0; 
end  loop; 

end  ACCELEROMETER; 
end  ATOD; 


begin  -  main  program 


ATOD.INITIALIZE_VELOCITY(INT_VEL); 

LINT_SEC  :=  INTEGER(SECONDS(CLOCK)); 

DISP_TIME  :=  DURATION(LINT_SEC)  -t-  0.8; 

ATOD.ACCELEROMETER.START; 

delay  (D1SP_TIME  -  SECONDS(CLOCKy  -  0.02); 

At6d.GET_VELOCITIES(VELOCITY); 

P0(X)  POSITION(X); 

P0(Y)  :=  POSmON(Y); 

P0(Z)  :=  POSITION(Z); 

B(0)(X)  ;=  P0(X); 

B(0)(Y)  ;=  P0(Y); 

B(0)(Z)  :=  P0(Z); 


POSITION  :=  POSITION  -  SIMPSON(POSITION,VELOCITY); 
DISP_TIME  :=  DISP_TIME  -i-  INTERVAL; 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
ATOD.GET_VELOCITIES(VELOCITY); 

P1(X)  :=  POSITION(X); 

P1(  Y)  :=  POSITION(Y); 

P1(Z)  :=  POSITION(Z); 

B(1)(X)  :=  P1(X); 

B(1)(Y)  :=  P1(Y); 

B(1)(Z)  ;=  P1(Z); 

POSITION  :=  POSITION  -  SIMPSON{POSrnON,VELOCITY); 
DISP_TIME  ;=  DISP_TIME  INTERVAL; 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
ATOD.GET_VELOCITIES(VELOCITY); 
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P2(X)  :=  POSITION(X); 

P2(Y)  :=  POSITION(Y); 

P2(Z)  :=  POSITION(Z); 

B(2)(X)  :=  P2(X); 

B(2)(Y)  ;=  P2(Y); 

B(2)(Z)  :=  P2(Z); 

POSITION  :=  POSITION  -  SIMPSON(POSmON,VELOCITY); 
DISP_TIME  ;=  DISP_TIME  +  INTERVAL; 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 

At6d.GET_  VELOCITIES  (VELOCITY); 

P3(X)  :=  POSITION(X); 

P3(Y)  :=  POSITION(Y); 

P3(Z)  :=  POSITION(Z); 

B(3)(X)  :=  P3(X); 

B(3)(Y)  ;=  P3(Y); 

B(3)(Z)  ;=  P3(Z); 


POSITION  :=  POSITION  -  SIMPSON(POSITION,VELOCITY); 
DISP.TI.ME  ;=  DISP_TIME  +  INTERVAL; 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
At6d.GET_VELOCITIES(VELOCITY); 

P4(X)  ;=  POSITION(X); 

P4(Y)  :=  POSmON(Y); 

P4(Z)  :=  POSITION(Z); 

B(4)(X)  ;=  P4(X); 

B(4)(Y)  :=  P4(Y); 

B(4)(Z)  :=  P4(Z); 


POSITION  :=  POSITION  -  SIMPSON(POSITION,VELOCITY); 
DISP_TLME  :=  DISP_TIME  +  INTERVAL; 
delay  (DISP^TIME  -  SECONDS(CLOCK)  -  0.02); 
ATOD.GET_VELOCITlES(VELOCITY); 

P5(X)  :=  POSITION(X); 

P5(Y)  :=  POSITION(Y); 

P5(Z)  :=  POSITION(Z); 

B(5)(X)  :=  P5(X); 

B(5)(Y)  :=  P5(Y); 

B(5)(Z)  :=  P5(Z); 


POSITION  :=  POSITION  -  SIMPSON(POSmON,VELOCITY); 
DISP_TIME  :=  DISP_TIME  +  INTERVAL; 
delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 


t 
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ATOD.GET_  VELOCITIES  (VELOCITY); 

P6{X)  :=  POSITION(X); 

P6(Y)  :=  POSITION(Y); 

P6(Z)  :=  POSITION(Z); 

B(6)(X)  :=  P6(X); 

B(6)(Y)  :=  P6(Y); 

B(6)(Z)  :=  P6(Z); 

POSITION  :=  POSITION  -  SIMPSON(POSITION, VELOCITY); 
DISP_TIME  :=  DISP_TIME  +  INTERVAL; 
while  NO_TARGET  =  FALSE  loop 
if  POSITION(X)  >  0.0  then 

ARRAY_IO.WRITE(C,  B); 

delay  (DISP_TIME  -  SECONDS(CLOCK)  -  0.02); 
ATOD.GET_VELOCITIES(VELOCITY); 

P(X)  ;=  POSmON(X); 

P(Y)  :=  POSITION(Y); 

PtZ)  :=  POSITION(Z); 

POSITION  :=  POSITION  -  SIMPSON(POSITION, VELOCITY); 
DISP.TIME  ;=  DISP.TIME  +  INTERVAL; 


P0(X)  :=  P1(X); 
P0(Y)  ;=  P1(Y); 
P0(Z)  :=  P1(Z); 


PKX)  :=  P2(X); 
P1(Y)  ;=  P2(Y); 
P1(Z)  ;=  P2(Z); 

P2(X)  ;=  P3(X); 
P2(Y)  ;=  P3(Y); 
P2(Z)  :=  P3(Z); 


P3(X)  :=  P4(X); 
P3(Y)  :=  P4(Y); 
P3(Z)  :=  P4(Z); 


P4(X)  :=  P5(X); 
P4(Y)  :=  P5(Y); 
P4(Z)  ;=  P5(Z); 
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P5(X)  :=  P6(X); 
P5(Y)  :=  P6(Y); 
P5(Z)  P6(Z); 


P6(X)  :=  P{X); 

P6(Y)  ;=  P(Y); 

P6(Z)  :=  P(Z); 

B(0)(X)  :=  P()(X); 

B(1)(X)  :=P1(X); 

B(2)(X)  ;=  P2(X); 

B(3)fX)  ;=P3(X); 

B(4)(X)  :=P4(X); 

B(5)(X)  :=P5(X); 

B(6)(X)  :=P6(X); 

B(0)(Y)  :=  PO{Y); 

BdXY)  :=  P1(Y); 

B(2)(Y)  :=  P2(Y); 

B(3)(Y)  :=  P3(Y); 

B(4')(Y)  :=  P4(Y); 

B(5kY)  :=P5(Y); 

B(6)(Y)  ;=  P6(Y); 

B(())(Z)  :=  PO(Z): 

B(1)(Z)  :=Pl(Z); 

B(2)(Z)  :=  P2(Z); 

B(3){Z)  :=P3(Z); 

B(4)(Z)  :=P4(Z): 

B(5)(Z)  :=  P5(Z); 

B(6)(Z)  :=  P6(Z); 
else 

NO_TARGET  :=  TRUE: 
end  if; 
end  loop; 

B(0)(X)  ;=  -1.00: 

ARRAY_IO.WRITE(C,  ((B(0)(X),others  =>  0.0),(others  =>  0.0),(others  =>  0.0), 
(others  =>  0.0),  (others  =>  0.0),  (others  =>  0.0),  (others  =>  0.0))); 

end  PROJ2; 


f 


131 


#  File:  makefile 


#  '  make  help"  to  print  option  list 

# 

#  Complete  development  cycle; 

#  make  family  -  makes  Ada  family  and  library  directories 

#  make  —  compiles,  links,  configures  source 

#  make  run  —  run  bootable  code 

MODE  =  s 
PROC  =  8 

OPTS  =  /$(MODE)  /t$(PROC) 

#  make  the  executable  code 

main.btl:  mainh.c$(PROC)$(MODE)  p  roj  1  h  .  c$  ( PRO  C)  $  ( MOD  E ) 

proj2h.c$(PROC)S(MODE)  main.pgm 
@  echo  EXPECT  1  WARNING... 
iconf  /s  main.pgm 
@  f:\util\bell 

mainh.c$(PROC)$(MODE):  projO.o  projOh  .t$(PROC)$(MODE) 
merger.tS(PROC)$(MODE)  mainh.t$(PROC)$(MODE) 

ilink  mainh.t$(PROC)${MODE)  projO.o  projOh.t$(PROC)$(MODE) 
merger. tS(PROC)$(MODE)  adansS.lib  hostio.lib  occamSs.lib 

projO.o:  common. ada  projO.ada 
ada  invoke  proj0.inv,yes 

projOh.t$(PROC)S(MODE):  proj0h2.tax  projOh.occ 
Occam  $(OPTS)  projOh.occ 

proj0h2.tax:  proj0h2.occ 
Occam  Aa  /x  proj0h2.occ 


merger. tS(PROC)$(MODE):  merger.occ 
Occam  $(OPTS)  merger.occ 

mainh.t$(PROC)$(MODE):  mainh.occ 
Occam  $(OPTS)  mainh.occ 


projlh.c$(PROC)$(MODE):  projl.o  projlh.t$(PROC)S(MODE) 

ilink  projlh.t$(PROC)$(MODE)  projl.o  adartsS.lib  hostio.lib  occamSs.lib 

projl.o:  common. ada  projl.ada 
ada  invoke  projl.inv.yes 

projlh.t$(PROC)$(MODE):  projlh2.tax  projlh.occ 
Occam  $(OPTS)  projlh.occ 

projlh2.tax:  projlh2.occ 
Occam  Aa  /x  projlh2.occ 

proj2h.c$(PROC)S(MODE);  proj2.o  proj2h.t$(PROC)S(MODE) 

ilink  proj2h.tS(PROC)$(MODE)  proj2.o  adartsS.lib  hostio.lib  occamSs.lib 

proj2.o:  common. ada  proj2.ada 
ada  invoke  proj2.inv,yes 

proj2h.tS(PROC)S(MODE):  proj2h2.tax  proj2h.occ 
Occam  $(OPTS)  proj2h.occ 

proj2h2.tax:  proj2h2.occ 
Occam  Aa  /x  proj2h2,occ 


# 

mi  sc. 

# 

run; 

iservcr  /sb  main.btl 

check: 
check  /r 

family: 

ada  invoke  family. inv, yes 
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—  File:  main.pgm 


#INCLUDE  "hostio.inc" 

#INCLUDE  "linkaddr.inc" 

#USE  "mainh.cSs" 

#USE  "projlh.cSs" 

#USE  "proj2h.c8s" 

CHAN  OF  INT  AdaChannel: 

CHAN  OF  INT  AdaChan: 

CHAN  OF  SP  FromFiler,  ToFiler: 

PLACED  PAR 

PROCESSOR  0  T8 

PLACE  FromFiler  AT  linkO.in: 

PLACE  ToFiler  AT  linkO.out; 

PLACE  AdaChannel  AT  link2.in: 

[1000001  INT  wsl: 

main. harness  (FromFiler,  ToFiler,  AdaChannel,  wsl) 

PROCESSOR  1  T8 

PLACE  AdaChannel  AT  link  Lout: 

PLACE  AdaChan  AT  link2.in: 

[1000001  INT  ws2: 

projl.harness  (AdaChannel,  AdaChan,  ws2) 

PROCESSOR  2  T8 

PLACE  AdaChan  AT  link3.out: 

[100000]  INT  ws3: 

proj2. harness  (AdaChan,  ws3) 
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